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

5443 lines
193 KiB
C++
Raw Normal View History

Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
//===-- Process.cpp ---------------------------------------------*- C++ -*-===//
//
// The LLVM Compiler Infrastructure
//
// This file is distributed under the University of Illinois Open Source
// License. See LICENSE.TXT for details.
//
//===----------------------------------------------------------------------===//
Fix Linux build warnings due to redefinition of macros: - add new header lldb-python.h to be included before other system headers - short term fix (eventually python dependencies must be cleaned up) Patch by Matt Kopec! llvm-svn: 169341
2012-12-05 08:20:57 +08:00
#include "lldb/lldb-python.h"
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
#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"
Make processes use InputReaders for their input. Move the process ReadThread stuff into the main Process class (out of the Process Plugins). This has the (intended) side effect of disabling the command line tool from reading input/commands while the process is running (the input is directed to the running process rather than to the command interpreter). llvm-svn: 119329
2010-11-16 13:07:41 +08:00
#include "lldb/Core/ConnectionFileDescriptor.h"
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
#include "lldb/Core/Debugger.h"
Make processes use InputReaders for their input. Move the process ReadThread stuff into the main Process class (out of the Process Plugins). This has the (intended) side effect of disabling the command line tool from reading input/commands while the process is running (the input is directed to the running process rather than to the command interpreter). llvm-svn: 119329
2010-11-16 13:07:41 +08:00
#include "lldb/Core/InputReader.h"
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
#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"
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
#include "lldb/Core/PluginManager.h"
#include "lldb/Core/State.h"
Modified the ArchSpec to take an optional "Platform *" when setting the triple. This allows you to have a platform selected, then specify a triple using "i386" and have the remaining triple items (vendor, os, and environment) set automatically. Many interpreter commands take the "--arch" option to specify an architecture triple, so now the command options needed to be able to get to the current platform, so the Options class now take a reference to the interpreter on construction. Modified the build LLVM building in the Xcode project to use the new Xcode project level user definitions: LLVM_BUILD_DIR - a path to the llvm build directory LLVM_SOURCE_DIR - a path to the llvm sources for the llvm that will be used to build lldb LLVM_CONFIGURATION - the configuration that lldb is built for (Release, Release+Asserts, Debug, Debug+Asserts). I also changed the LLVM build to not check if "lldb/llvm" is a symlink and then assume it is a real llvm build directory versus the unzipped llvm.zip package, so now you can actually have a "lldb/llvm" directory in your lldb sources. llvm-svn: 129112
2011-04-08 06:46:35 +08:00
#include "lldb/Expression/ClangUserExpression.h"
This is a very large commit that completely re-does the way lldb handles user settable internal variables (the equivalent of set/show variables in gdb). In addition to the basic infrastructure (most of which is defined in UserSettingsController.{h,cpp}, there are examples of two classes that have been set up to contain user settable variables (the Debugger and Process classes). The 'settings' command has been modified to be a command-subcommand structure, and the 'set', 'show' and 'append' commands have been moved into this sub-commabnd structure. The old StateVariable class has been completely replaced by this, and the state variable dictionary has been removed from the Command Interpreter. Places that formerly accessed the state variable mechanism have been modified to access the variables in this new structure instead (checking the term-width; getting/checking the prompt; etc.) Variables are attached to classes; there are two basic "flavors" of variables that can be set: "global" variables (static/class-wide), and "instance" variables (one per instance of the class). The whole thing has been set up so that any global or instance variable can be set at any time (e.g. on start up, in your .lldbinit file), whether or not any instances actually exist (there's a whole pending and default values mechanism to help deal with that). llvm-svn: 113041
2010-09-04 08:03:46 +08:00
#include "lldb/Interpreter/CommandInterpreter.h"
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
#include "lldb/Host/Host.h"
#include "lldb/Target/ABI.h"
Added support for loading and unloading shared libraries. This was done by adding support into lldb_private::Process: virtual uint32_t lldb_private::Process::LoadImage (const FileSpec &image_spec, Error &error); virtual Error lldb_private::Process::UnloadImage (uint32_t image_token); There is a default implementation that should work for both linux and MacOSX. This ability has also been exported through the SBProcess API: uint32_t lldb::SBProcess::LoadImage (lldb::SBFileSpec &image_spec, lldb::SBError &error); lldb::SBError lldb::SBProcess::UnloadImage (uint32_t image_token); Modified the DynamicLoader plug-in interface to require it to be able to tell us if it is currently possible to load/unload a shared library: virtual lldb_private::Error DynamicLoader::CanLoadImage () = 0; This way the dynamic loader plug-ins are allows to veto whether we can currently load a shared library since the dynamic loader might know if it is currenlty loading/unloading shared libraries. It might also know about the current host system and know where to check to make sure runtime or malloc locks are currently being held. Modified the expression parser to have ClangUserExpression::Evaluate() be the one that causes the dynamic checkers to be loaded instead of other code that shouldn't have to worry about it. llvm-svn: 118227
2010-11-04 09:54:29 +08:00
#include "lldb/Target/DynamicLoader.h"
Added a new plug-in type: lldb_private::OperatingSystem. The operating system plug-ins are add on plug-ins for the lldb_private::Process class that can add thread contexts that are read from memory. It is common in kernels to have a lot of threads that are not currently executing on any cores (JTAG debugging also follows this sort of thing) and are context switched out whose state is stored in memory data structures. Clients can now subclass the OperatingSystem plug-ins and then make sure their Create functions correcltly only enable themselves when the right binary/target triple are being debugged. The operating system plug-ins get a chance to attach themselves to processes just after launching or attaching and are given a lldb_private::Process object pointer which can be inspected to see if the main executable, target triple, or any shared libraries match a case where the OS plug-in should be used. Currently the OS plug-ins can create new threads, define the register contexts for these threads (which can all be different if desired), and populate and manage the thread info (stop reason, registers in the register context) as the debug session goes on. llvm-svn: 138228
2011-08-22 10:49:39 +08:00
#include "lldb/Target/OperatingSystem.h"
Committing the skeleton of Language runtime plugin classes. llvm-svn: 114620
2010-09-23 10:01:19 +08:00
#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"
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
#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"
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
#include "lldb/Target/Target.h"
#include "lldb/Target/TargetList.h"
#include "lldb/Target/Thread.h"
#include "lldb/Target/ThreadPlan.h"
Two changes, 1) Start the PrivateStateThread stopped, and then in StartPrivateStateThread, make the private state thread and then resume it before we say the thread is created. That way we know it is listening for events by the time we get out of StartPrivateStateThread. 2) Backstop running a thread plan when calling Process::RunThreadPlan on the private state thread with a ThreadPlanBase so that running the plan doesn't pass its stop events to whatever plans happen to be above us on the thread plan stack. llvm-svn: 154368
2012-04-10 09:21:57 +08:00
#include "lldb/Target/ThreadPlanBase.h"
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
using namespace lldb;
using namespace lldb_private;
Reimplemented the code that backed the "settings" in lldb. There were many issues with the previous implementation: - no setting auto completion - very manual and error prone way of getting/setting variables - tons of code duplication - useless instance names for processes, threads Now settings can easily be defined like option values. The new settings makes use of the "OptionValue" classes so we can re-use the option value code that we use to set settings in command options. No more instances, just "does the right thing". llvm-svn: 162366
2012-08-23 01:17:09 +08:00
// 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." },
Add an example of using the target.process.extra-startup-command to turn on debugserver logging since we always forget how to do this... llvm-svn: 168840
2012-11-29 08:41:12 +08:00
{ "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;\"" },
Change the default behavior for unwinding and breakpoints when running expressions. <rdar://problem/13121442> llvm-svn: 174082
2013-02-01 03:48:57 +08:00
{ "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." },
<rdar://problem/12655594> Be sure to resolve the file path for the "target.process.python-os-plugin-path" setting. llvm-svn: 168916
2012-11-30 02:48:47 +08:00
{ "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." },
Add "target.process.stop-on-shared-library-events" setting, and make it work. Add the ability to give breakpoints a "kind" string, and have the StopInfoBreakpoint print that in the brief description if set. Also print the kind - if set - in the breakpoint listing. Give kinds to a bunch of the internal breakpoints. We were deleting the Mac OS X dynamic loader breakpoint as though the id we had stored away was a breakpoint site ID, but in fact it was a breakpoint id, so we never actually deleted it. Fixed that. llvm-svn: 173555
2013-01-26 10:19:28 +08:00
{ "stop-on-sharedlibrary-events" , OptionValue::eTypeBoolean, true, false, NULL, NULL, "If true, stop when a shared library is loaded or unloaded." },
Reimplemented the code that backed the "settings" in lldb. There were many issues with the previous implementation: - no setting auto completion - very manual and error prone way of getting/setting variables - tons of code duplication - useless instance names for processes, threads Now settings can easily be defined like option values. The new settings makes use of the "OptionValue" classes so we can re-use the option value code that we use to set settings in command options. No more instances, just "does the right thing". llvm-svn: 162366
2012-08-23 01:17:09 +08:00
{ NULL , OptionValue::eTypeInvalid, false, 0, NULL, NULL, NULL }
};
enum {
ePropertyDisableMemCache,
<rdar://problem/12491420> Added a new setting that allows a python OS plug-in to detect threads and provide registers for memory threads. To enable this you set the setting: settings set target.process.python-os-plugin-path lldb/examples/python/operating_system.py Then run your program and see the extra threads. llvm-svn: 166244
2012-10-19 06:40:37 +08:00
ePropertyExtraStartCommand,
Separated the "expr --unwind-on-error" behavior into two parts, actual errors (i.e. crashes) which continue to be controlled by the --unwind-on-error flag, and --ignore-breakpoint which separately controls behavior when a called function hits a breakpoint. For breakpoints, we don't unwind, we either stop, or ignore the breakpoint, which makes more sense. Also make both these behaviors globally settable through "settings set". Also handle the case where a breakpoint command calls code that ends up re-hitting the breakpoint. We were recursing and crashing. Now we just stop without calling the second command. <rdar://problem/12986644> <rdar://problem/9119325> llvm-svn: 172503
2013-01-15 10:47:48 +08:00
ePropertyIgnoreBreakpointsInExpressions,
ePropertyUnwindOnErrorInExpressions,
Add "target.process.stop-on-shared-library-events" setting, and make it work. Add the ability to give breakpoints a "kind" string, and have the StopInfoBreakpoint print that in the brief description if set. Also print the kind - if set - in the breakpoint listing. Give kinds to a bunch of the internal breakpoints. We were deleting the Mac OS X dynamic loader breakpoint as though the id we had stored away was a breakpoint site ID, but in fact it was a breakpoint id, so we never actually deleted it. Fixed that. llvm-svn: 173555
2013-01-26 10:19:28 +08:00
ePropertyPythonOSPluginPath,
ePropertyStopOnSharedLibraryEvents
Reimplemented the code that backed the "settings" in lldb. There were many issues with the previous implementation: - no setting auto completion - very manual and error prone way of getting/setting variables - tons of code duplication - useless instance names for processes, threads Now settings can easily be defined like option values. The new settings makes use of the "OptionValue" classes so we can re-use the option value code that we use to set settings in command options. No more instances, just "does the right thing". llvm-svn: 162366
2012-08-23 01:17:09 +08:00
};
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"),
Add "target.process.stop-on-shared-library-events" setting, and make it work. Add the ability to give breakpoints a "kind" string, and have the StopInfoBreakpoint print that in the brief description if set. Also print the kind - if set - in the breakpoint listing. Give kinds to a bunch of the internal breakpoints. We were deleting the Mac OS X dynamic loader breakpoint as though the id we had stored away was a breakpoint site ID, but in fact it was a breakpoint id, so we never actually deleted it. Fixed that. llvm-svn: 173555
2013-01-26 10:19:28 +08:00
ConstString("Settings specific to threads."),
Reimplemented the code that backed the "settings" in lldb. There were many issues with the previous implementation: - no setting auto completion - very manual and error prone way of getting/setting variables - tons of code duplication - useless instance names for processes, threads Now settings can easily be defined like option values. The new settings makes use of the "OptionValue" classes so we can re-use the option value code that we use to set settings in command options. No more instances, just "does the right thing". llvm-svn: 162366
2012-08-23 01:17:09 +08:00
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);
}
<rdar://problem/12491420> Added a new setting that allows a python OS plug-in to detect threads and provide registers for memory threads. To enable this you set the setting: settings set target.process.python-os-plugin-path lldb/examples/python/operating_system.py Then run your program and see the extra threads. llvm-svn: 166244
2012-10-19 06:40:37 +08:00
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);
}
Separated the "expr --unwind-on-error" behavior into two parts, actual errors (i.e. crashes) which continue to be controlled by the --unwind-on-error flag, and --ignore-breakpoint which separately controls behavior when a called function hits a breakpoint. For breakpoints, we don't unwind, we either stop, or ignore the breakpoint, which makes more sense. Also make both these behaviors globally settable through "settings set". Also handle the case where a breakpoint command calls code that ends up re-hitting the breakpoint. We were recursing and crashing. Now we just stop without calling the second command. <rdar://problem/12986644> <rdar://problem/9119325> llvm-svn: 172503
2013-01-15 10:47:48 +08:00
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);
}
Add "target.process.stop-on-shared-library-events" setting, and make it work. Add the ability to give breakpoints a "kind" string, and have the StopInfoBreakpoint print that in the brief description if set. Also print the kind - if set - in the breakpoint listing. Give kinds to a bunch of the internal breakpoints. We were deleting the Mac OS X dynamic loader breakpoint as though the id we had stored away was a breakpoint site ID, but in fact it was a breakpoint id, so we never actually deleted it. Fixed that. llvm-svn: 173555
2013-01-26 10:19:28 +08:00
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);
}
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;
Added the ability to get a broadcaster event name for a given broadcaster event. Modified the ProcessInfo structure to contain all process arguments. Using the new function calls on MacOSX allows us to see the full process name, not just the first 16 characters. Added a new platform command: "platform process info <pid> [<pid> <pid> ...]" that can be used to get detailed information for a process including all arguments, user and group info and more. llvm-svn: 128694
2011-04-01 08:29:43 +08:00
if (m_pid != LLDB_INVALID_PROCESS_ID)
Resolve printf formatting warnings on Linux: - use macros from inttypes.h for format strings instead of OS-specific types Patch from Matt Kopec! llvm-svn: 168945
2012-11-30 05:49:15 +08:00
s.Printf (" pid = %" PRIu64 "\n", m_pid);
Added the ability to get a broadcaster event name for a given broadcaster event. Modified the ProcessInfo structure to contain all process arguments. Using the new function calls on MacOSX allows us to see the full process name, not just the first 16 characters. Added a new platform command: "platform process info <pid> [<pid> <pid> ...]" that can be used to get detailed information for a process including all arguments, user and group info and more. llvm-svn: 128694
2011-04-01 08:29:43 +08:00
if (m_parent_pid != LLDB_INVALID_PROCESS_ID)
Resolve printf formatting warnings on Linux: - use macros from inttypes.h for format strings instead of OS-specific types Patch from Matt Kopec! llvm-svn: 168945
2012-11-30 05:49:15 +08:00
s.Printf (" parent = %" PRIu64 "\n", m_parent_pid);
Added the ability to get a broadcaster event name for a given broadcaster event. Modified the ProcessInfo structure to contain all process arguments. Using the new function calls on MacOSX allows us to see the full process name, not just the first 16 characters. Added a new platform command: "platform process info <pid> [<pid> <pid> ...]" that can be used to get detailed information for a process including all arguments, user and group info and more. llvm-svn: 128694
2011-04-01 08:29:43 +08:00
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();
Added the ability to get a broadcaster event name for a given broadcaster event. Modified the ProcessInfo structure to contain all process arguments. Using the new function calls on MacOSX allows us to see the full process name, not just the first 16 characters. Added a new platform command: "platform process info <pid> [<pid> <pid> ...]" that can be used to get detailed information for a process including all arguments, user and group info and more. llvm-svn: 128694
2011-04-01 08:29:43 +08:00
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);
Added the ability to get a broadcaster event name for a given broadcaster event. Modified the ProcessInfo structure to contain all process arguments. Using the new function calls on MacOSX allows us to see the full process name, not just the first 16 characters. Added a new platform command: "platform process info <pid> [<pid> <pid> ...]" that can be used to get detailed information for a process including all arguments, user and group info and more. llvm-svn: 128694
2011-04-01 08:29:43 +08:00
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);
Added the ability to get a broadcaster event name for a given broadcaster event. Modified the ProcessInfo structure to contain all process arguments. Using the new function calls on MacOSX allows us to see the full process name, not just the first 16 characters. Added a new platform command: "platform process info <pid> [<pid> <pid> ...]" that can be used to get detailed information for a process including all arguments, user and group info and more. llvm-svn: 128694
2011-04-01 08:29:43 +08:00
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);
Added the ability to get a broadcaster event name for a given broadcaster event. Modified the ProcessInfo structure to contain all process arguments. Using the new function calls on MacOSX allows us to see the full process name, not just the first 16 characters. Added a new platform command: "platform process info <pid> [<pid> <pid> ...]" that can be used to get detailed information for a process including all arguments, user and group info and more. llvm-svn: 128694
2011-04-01 08:29:43 +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 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);
}
}
Added the ability to get a broadcaster event name for a given broadcaster event. Modified the ProcessInfo structure to contain all process arguments. Using the new function calls on MacOSX allows us to see the full process name, not just the first 16 characters. Added a new platform command: "platform process info <pid> [<pid> <pid> ...]" that can be used to get detailed information for a process including all arguments, user and group info and more. llvm-svn: 128694
2011-04-01 08:29:43 +08:00
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";
Added the ability to get a broadcaster event name for a given broadcaster event. Modified the ProcessInfo structure to contain all process arguments. Using the new function calls on MacOSX allows us to see the full process name, not just the first 16 characters. Added a new platform command: "platform process info <pid> [<pid> <pid> ...]" that can be used to get detailed information for a process including all arguments, user and group info and more. llvm-svn: 128694
2011-04-01 08:29:43 +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
s.Printf ("PID PARENT USER GROUP EFF USER EFF GROUP TRIPLE %s\n", label);
Added the ability to get a broadcaster event name for a given broadcaster event. Modified the ProcessInfo structure to contain all process arguments. Using the new function calls on MacOSX allows us to see the full process name, not just the first 16 characters. Added a new platform command: "platform process info <pid> [<pid> <pid> ...]" that can be used to get detailed information for a process including all arguments, user and group info and more. llvm-svn: 128694
2011-04-01 08:29:43 +08:00
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);
Added the ability to get a broadcaster event name for a given broadcaster event. Modified the ProcessInfo structure to contain all process arguments. Using the new function calls on MacOSX allows us to see the full process name, not just the first 16 characters. Added a new platform command: "platform process info <pid> [<pid> <pid> ...]" that can be used to get detailed information for a process including all arguments, user and group info and more. llvm-svn: 128694
2011-04-01 08:29:43 +08:00
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;
Resolve printf formatting warnings on Linux: - use macros from inttypes.h for format strings instead of OS-specific types Patch from Matt Kopec! llvm-svn: 168945
2012-11-30 05:49:15 +08:00
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
Added the ability to get a broadcaster event name for a given broadcaster event. Modified the ProcessInfo structure to contain all process arguments. Using the new function calls on MacOSX allows us to see the full process name, not just the first 16 characters. Added a new platform command: "platform process info <pid> [<pid> <pid> ...]" that can be used to get detailed information for a process including all arguments, user and group info and more. llvm-svn: 128694
2011-04-01 08:29:43 +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);
Added the ability to get a broadcaster event name for a given broadcaster event. Modified the ProcessInfo structure to contain all process arguments. Using the new function calls on MacOSX allows us to see the full process name, not just the first 16 characters. Added a new platform command: "platform process info <pid> [<pid> <pid> ...]" that can be used to get detailed information for a process including all arguments, user and group info and more. llvm-svn: 128694
2011-04-01 08:29:43 +08:00
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);
Added the ability to get a broadcaster event name for a given broadcaster event. Modified the ProcessInfo structure to contain all process arguments. Using the new function calls on MacOSX allows us to see the full process name, not just the first 16 characters. Added a new platform command: "platform process info <pid> [<pid> <pid> ...]" that can be used to get detailed information for a process including all arguments, user and group info and more. llvm-svn: 128694
2011-04-01 08:29:43 +08:00
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);
Added the ability to get a broadcaster event name for a given broadcaster event. Modified the ProcessInfo structure to contain all process arguments. Using the new function calls on MacOSX allows us to see the full process name, not just the first 16 characters. Added a new platform command: "platform process info <pid> [<pid> <pid> ...]" that can be used to get detailed information for a process including all arguments, user and group info and more. llvm-svn: 128694
2011-04-01 08:29:43 +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);
Added the ability to get a broadcaster event name for a given broadcaster event. Modified the ProcessInfo structure to contain all process arguments. Using the new function calls on MacOSX allows us to see the full process name, not just the first 16 characters. Added a new platform command: "platform process info <pid> [<pid> <pid> ...]" that can be used to get detailed information for a process including all arguments, user and group info and more. llvm-svn: 128694
2011-04-01 08:29:43 +08:00
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);
Added the ability to get a broadcaster event name for a given broadcaster event. Modified the ProcessInfo structure to contain all process arguments. Using the new function calls on MacOSX allows us to see the full process name, not just the first 16 characters. Added a new platform command: "platform process info <pid> [<pid> <pid> ...]" that can be used to get detailed information for a process including all arguments, user and group info and more. llvm-svn: 128694
2011-04-01 08:29:43 +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);
Added the ability to get a broadcaster event name for a given broadcaster event. Modified the ProcessInfo structure to contain all process arguments. Using the new function calls on MacOSX allows us to see the full process name, not just the first 16 characters. Added a new platform command: "platform process info <pid> [<pid> <pid> ...]" that can be used to get detailed information for a process including all arguments, user and group info and more. llvm-svn: 128694
2011-04-01 08:29:43 +08:00
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);
Added the ability to get a broadcaster event name for a given broadcaster event. Modified the ProcessInfo structure to contain all process arguments. Using the new function calls on MacOSX allows us to see the full process name, not just the first 16 characters. Added a new platform command: "platform process info <pid> [<pid> <pid> ...]" that can be used to get detailed information for a process including all arguments, user and group info and more. llvm-svn: 128694
2011-04-01 08:29:43 +08:00
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
Added the ability to get a broadcaster event name for a given broadcaster event. Modified the ProcessInfo structure to contain all process arguments. Using the new function calls on MacOSX allows us to see the full process name, not just the first 16 characters. Added a new platform command: "platform process info <pid> [<pid> <pid> ...]" that can be used to get detailed information for a process including all arguments, user and group info and more. llvm-svn: 128694
2011-04-01 08:29:43 +08:00
{
Update declarations for all functions/methods that accept printf-style stdarg formats to use __attribute__ format so the compiler can flag incorrect uses. Fix all incorrect uses. Most of these are innocuous, a few were resulting in crashes. llvm-svn: 140185
2011-09-21 05:44:10 +08:00
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),
Added the ability to get a broadcaster event name for a given broadcaster event. Modified the ProcessInfo structure to contain all process arguments. Using the new function calls on MacOSX allows us to see the full process name, not just the first 16 characters. Added a new platform command: "platform process info <pid> [<pid> <pid> ...]" that can be used to get detailed information for a process including all arguments, user and group info and more. llvm-svn: 128694
2011-04-01 08:29:43 +08:00
(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)
Added the ability to get a broadcaster event name for a given broadcaster event. Modified the ProcessInfo structure to contain all process arguments. Using the new function calls on MacOSX allows us to see the full process name, not just the first 16 characters. Added a new platform command: "platform process info <pid> [<pid> <pid> ...]" that can be used to get detailed information for a process including all arguments, user and group info and more. llvm-svn: 128694
2011-04-01 08:29:43 +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 uint32_t argc = m_arguments.GetArgumentCount();
Added the ability to get a broadcaster event name for a given broadcaster event. Modified the ProcessInfo structure to contain all process arguments. Using the new function calls on MacOSX allows us to see the full process name, not just the first 16 characters. Added a new platform command: "platform process info <pid> [<pid> <pid> ...]" that can be used to get detailed information for a process including all arguments, user and group info and more. llvm-svn: 128694
2011-04-01 08:29:43 +08:00
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));
Added the ability to get a broadcaster event name for a given broadcaster event. Modified the ProcessInfo structure to contain all process arguments. Using the new function calls on MacOSX allows us to see the full process name, not just the first 16 characters. Added a new platform command: "platform process info <pid> [<pid> <pid> ...]" that can be used to get detailed information for a process including all arguments, user and group info and more. llvm-svn: 128694
2011-04-01 08:29:43 +08:00
}
}
}
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
Added the ability to get a broadcaster event name for a given broadcaster event. Modified the ProcessInfo structure to contain all process arguments. Using the new function calls on MacOSX allows us to see the full process name, not just the first 16 characters. Added a new platform command: "platform process info <pid> [<pid> <pid> ...]" that can be used to get detailed information for a process including all arguments, user and group info and more. llvm-svn: 128694
2011-04-01 08:29:43 +08:00
{
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
Added the ability to get a broadcaster event name for a given broadcaster event. Modified the ProcessInfo structure to contain all process arguments. Using the new function calls on MacOSX allows us to see the full process name, not just the first 16 characters. Added a new platform command: "platform process info <pid> [<pid> <pid> ...]" that can be used to get detailed information for a process including all arguments, user and group info and more. llvm-svn: 128694
2011-04-01 08:29:43 +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
<rdar://problem/12462048> LLDB changes argv[0] when debugging a symlink. Now we have the notion of argv0 in the target settings: target.arg0 (string) = There is also the program argument that are separate from the first argument that have existed for a while: target.run-args (arguments) = When running "target create <exe>", we will place the untouched "<exe>" into target.arg0 to ensure when we run, we run with what the user typed. This has been added to the ProcessLaunchInfo and all other needed places so we always carry around the: - resolved executable path - argv0 - program args Some systems may not support separating argv0 from the resolved executable path and the ProcessLaunchInfo needs to carry all of this information along so that each platform can make that decision. llvm-svn: 166137
2012-10-18 06:57:12 +08:00
ProcessInfo::SetArguments (char const **argv, bool first_arg_is_executable)
Modified all Process::Launch() calls to use a ProcessLaunchInfo structure on internal only (public API hasn't changed) to simplify the paramter list to the launch calls down into just one argument. Also all of the argument, envronment and stdio things are now handled in a much more centralized fashion. llvm-svn: 143656
2011-11-04 05:22:33 +08:00
{
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
<rdar://problem/12462048> LLDB changes argv[0] when debugging a symlink. Now we have the notion of argv0 in the target settings: target.arg0 (string) = There is also the program argument that are separate from the first argument that have existed for a while: target.run-args (arguments) = When running "target create <exe>", we will place the untouched "<exe>" into target.arg0 to ensure when we run, we run with what the user typed. This has been added to the ProcessLaunchInfo and all other needed places so we always carry around the: - resolved executable path - argv0 - program args Some systems may not support separating argv0 from the resolved executable path and the ProcessLaunchInfo needs to carry all of this information along so that each platform can make that decision. llvm-svn: 166137
2012-10-18 06:57:12 +08:00
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)
{
Modified all Process::Launch() calls to use a ProcessLaunchInfo structure on internal only (public API hasn't changed) to simplify the paramter list to the launch calls down into just one argument. Also all of the argument, envronment and stdio things are now handled in a much more centralized fashion. llvm-svn: 143656
2011-11-04 05:22:33 +08:00
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);
}
}
}
Moved many of the "settings" that used to be in "target.process.*" to just be in the target. All of the environment, args, stdin/out/err files, etc have all been moved. Also re-enabled the ability to launch a process in a separate terminal on MacOSX. llvm-svn: 144061
2011-11-08 10:43:13 +08:00
void
Use a pseudoterminal for local processes if no STDIO redirection or other file actions have been specified. llvm-svn: 144922
2011-11-18 06:14:31 +08:00
ProcessLaunchInfo::FinalizeFileActions (Target *target, bool default_to_use_pty)
Moved many of the "settings" that used to be in "target.process.*" to just be in the target. All of the environment, args, stdin/out/err files, etc have all been moved. Also re-enabled the ability to launch a process in a separate terminal on MacOSX. llvm-svn: 144061
2011-11-08 10:43:13 +08:00
{
// 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))
{
<rdar://problem/10840355> Fixed STDERR to not be opened as readable. Also cleaned up some of the code that implemented the file actions as some of the code was using the wrong variables, they now use the right ones (in for stdin, out for stdout, err for stderr). llvm-svn: 152102
2012-03-06 12:01:04 +08:00
AppendSuppressFileAction (STDIN_FILENO , true, false);
AppendSuppressFileAction (STDOUT_FILENO, false, true);
AppendSuppressFileAction (STDERR_FILENO, false, true);
Moved many of the "settings" that used to be in "target.process.*" to just be in the target. All of the environment, args, stdin/out/err files, etc have all been moved. Also re-enabled the ability to launch a process in a separate terminal on MacOSX. llvm-svn: 144061
2011-11-08 10:43:13 +08:00
}
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
Reimplemented the code that backed the "settings" in lldb. There were many issues with the previous implementation: - no setting auto completion - very manual and error prone way of getting/setting variables - tons of code duplication - useless instance names for processes, threads Now settings can easily be defined like option values. The new settings makes use of the "OptionValue" classes so we can re-use the option value code that we use to set settings in command options. No more instances, just "does the right thing". llvm-svn: 162366
2012-08-23 01:17:09 +08:00
FileSpec in_path;
FileSpec out_path;
FileSpec err_path;
Moved many of the "settings" that used to be in "target.process.*" to just be in the target. All of the environment, args, stdin/out/err files, etc have all been moved. Also re-enabled the ability to launch a process in a separate terminal on MacOSX. llvm-svn: 144061
2011-11-08 10:43:13 +08:00
if (target)
{
<rdar://problem/10840355> Fixed STDERR to not be opened as readable. Also cleaned up some of the code that implemented the file actions as some of the code was using the wrong variables, they now use the right ones (in for stdin, out for stdout, err for stderr). llvm-svn: 152102
2012-03-06 12:01:04 +08:00
in_path = target->GetStandardInputPath();
out_path = target->GetStandardOutputPath();
err_path = target->GetStandardErrorPath();
Use a pseudoterminal for local processes if no STDIO redirection or other file actions have been specified. llvm-svn: 144922
2011-11-18 06:14:31 +08:00
}
Reimplemented the code that backed the "settings" in lldb. There were many issues with the previous implementation: - no setting auto completion - very manual and error prone way of getting/setting variables - tons of code duplication - useless instance names for processes, threads Now settings can easily be defined like option values. The new settings makes use of the "OptionValue" classes so we can re-use the option value code that we use to set settings in command options. No more instances, just "does the right thing". llvm-svn: 162366
2012-08-23 01:17:09 +08:00
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)
Use a pseudoterminal for local processes if no STDIO redirection or other file actions have been specified. llvm-svn: 144922
2011-11-18 06:14:31 +08:00
{
if (m_pty.OpenFirstAvailableMaster (O_RDWR|O_NOCTTY, NULL, 0))
Moved many of the "settings" that used to be in "target.process.*" to just be in the target. All of the environment, args, stdin/out/err files, etc have all been moved. Also re-enabled the ability to launch a process in a separate terminal on MacOSX. llvm-svn: 144061
2011-11-08 10:43:13 +08:00
{
Reimplemented the code that backed the "settings" in lldb. There were many issues with the previous implementation: - no setting auto completion - very manual and error prone way of getting/setting variables - tons of code duplication - useless instance names for processes, threads Now settings can easily be defined like option values. The new settings makes use of the "OptionValue" classes so we can re-use the option value code that we use to set settings in command options. No more instances, just "does the right thing". llvm-svn: 162366
2012-08-23 01:17:09 +08:00
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);
Moved many of the "settings" that used to be in "target.process.*" to just be in the target. All of the environment, args, stdin/out/err files, etc have all been moved. Also re-enabled the ability to launch a process in a separate terminal on MacOSX. llvm-svn: 144061
2011-11-08 10:43:13 +08:00
}
}
}
}
}
Added a new class to Process.h: ProcessAttachInfo. This class contains enough info for us to attach by pid, or by name and will also allow us to eventually do a lot more powerful attaches. If you look at the options for the "platform process list" command, there are many options which we should be able to specify. This will allow us to do things like "attach to a process named 'tcsh' that has a parent process ID of 123", or "attach to a process named 'x' which has an effective user ID of 345". I finished up the --shell implementation so that it can be used without the --tty option in "process launch". The "--shell" option now can take an optional argument which is the path to the shell to use (or a partial name like "sh" which we will find using the current PATH environment variable). Modified the Process::Attach to use the new ProcessAttachInfo as the sole argument and centralized a lot of code that was in the "process attach" Execute function so that everyone can take advantage of the powerful new attach functionality. llvm-svn: 144615
2011-11-15 11:53:30 +08:00
bool
Added a new host function that allows us to run shell command and get the output from them along with the status and signal: Error Host::RunShellCommand (const char *command, const char *working_dir, int *status_ptr, int *signo_ptr, std::string *command_output_ptr, uint32_t timeout_sec); This will allow us to use this functionality in the host lldb_private::Platform, and also use it in our lldb-platform binary. It leverages the existing code in Host::LaunchProcess and ProcessLaunchInfo. llvm-svn: 154730
2012-04-14 09:42:46 +08:00
ProcessLaunchInfo::ConvertArgumentsForLaunchingInShell (Error &error,
bool localhost,
bool will_debug,
bool first_arg_is_full_shell_command)
Added a new class to Process.h: ProcessAttachInfo. This class contains enough info for us to attach by pid, or by name and will also allow us to eventually do a lot more powerful attaches. If you look at the options for the "platform process list" command, there are many options which we should be able to specify. This will allow us to do things like "attach to a process named 'tcsh' that has a parent process ID of 123", or "attach to a process named 'x' which has an effective user ID of 345". I finished up the --shell implementation so that it can be used without the --tty option in "process launch". The "--shell" option now can take an optional argument which is the path to the shell to use (or a partial name like "sh" which we will find using the current PATH environment variable). Modified the Process::Attach to use the new ProcessAttachInfo as the sole argument and centralized a lot of code that was in the "process attach" Execute function so that everyone can take advantage of the powerful new attach functionality. llvm-svn: 144615
2011-11-15 11:53:30 +08:00
{
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;
}
<rdar://problem/12462048> LLDB changes argv[0] when debugging a symlink. Now we have the notion of argv0 in the target settings: target.arg0 (string) = There is also the program argument that are separate from the first argument that have existed for a while: target.run-args (arguments) = When running "target create <exe>", we will place the untouched "<exe>" into target.arg0 to ensure when we run, we run with what the user typed. This has been added to the ProcessLaunchInfo and all other needed places so we always carry around the: - resolved executable path - argv0 - program args Some systems may not support separating argv0 from the resolved executable path and the ProcessLaunchInfo needs to carry all of this information along so that each platform can make that decision. llvm-svn: 166137
2012-10-18 06:57:12 +08:00
const char **argv = GetArguments().GetConstArgumentVector ();
if (argv == NULL || argv[0] == NULL)
return false;
Added a new class to Process.h: ProcessAttachInfo. This class contains enough info for us to attach by pid, or by name and will also allow us to eventually do a lot more powerful attaches. If you look at the options for the "platform process list" command, there are many options which we should be able to specify. This will allow us to do things like "attach to a process named 'tcsh' that has a parent process ID of 123", or "attach to a process named 'x' which has an effective user ID of 345". I finished up the --shell implementation so that it can be used without the --tty option in "process launch". The "--shell" option now can take an optional argument which is the path to the shell to use (or a partial name like "sh" which we will find using the current PATH environment variable). Modified the Process::Attach to use the new ProcessAttachInfo as the sole argument and centralized a lot of code that was in the "process attach" Execute function so that everyone can take advantage of the powerful new attach functionality. llvm-svn: 144615
2011-11-15 11:53:30 +08:00
Args shell_arguments;
std::string safe_arg;
shell_arguments.AppendArgument (shell_executable);
shell_arguments.AppendArgument ("-c");
Added a new host function that allows us to run shell command and get the output from them along with the status and signal: Error Host::RunShellCommand (const char *command, const char *working_dir, int *status_ptr, int *signo_ptr, std::string *command_output_ptr, uint32_t timeout_sec); This will allow us to use this functionality in the host lldb_private::Platform, and also use it in our lldb-platform binary. It leverages the existing code in Host::LaunchProcess and ProcessLaunchInfo. llvm-svn: 154730
2012-04-14 09:42:46 +08:00
StreamString shell_command;
if (will_debug)
Added a new class to Process.h: ProcessAttachInfo. This class contains enough info for us to attach by pid, or by name and will also allow us to eventually do a lot more powerful attaches. If you look at the options for the "platform process list" command, there are many options which we should be able to specify. This will allow us to do things like "attach to a process named 'tcsh' that has a parent process ID of 123", or "attach to a process named 'x' which has an effective user ID of 345". I finished up the --shell implementation so that it can be used without the --tty option in "process launch". The "--shell" option now can take an optional argument which is the path to the shell to use (or a partial name like "sh" which we will find using the current PATH environment variable). Modified the Process::Attach to use the new ProcessAttachInfo as the sole argument and centralized a lot of code that was in the "process attach" Execute function so that everyone can take advantage of the powerful new attach functionality. llvm-svn: 144615
2011-11-15 11:53:30 +08:00
{
<rdar://problem/12462048> LLDB changes argv[0] when debugging a symlink. Now we have the notion of argv0 in the target settings: target.arg0 (string) = There is also the program argument that are separate from the first argument that have existed for a while: target.run-args (arguments) = When running "target create <exe>", we will place the untouched "<exe>" into target.arg0 to ensure when we run, we run with what the user typed. This has been added to the ProcessLaunchInfo and all other needed places so we always carry around the: - resolved executable path - argv0 - program args Some systems may not support separating argv0 from the resolved executable path and the ProcessLaunchInfo needs to carry all of this information along so that each platform can make that decision. llvm-svn: 166137
2012-10-18 06:57:12 +08:00
// 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();
<rdar://problem/13200878> When launching in the shell, make sure if you specify a relative path, and if the current working directory has a space in it, that we don't hose the shell invocation. Currently if we launch with a relative path, we prepend the current working directory to the PATH using: PATH=`cwd`:$PATH a.out ... We needed to add quotes around the value for PATH to make sure if any paths in PATH contained spaces, that we don't hose the shell command. Now we do a: PATH="`cwd`:$PATH" a.out ... llvm-svn: 175135
2013-02-14 11:54:39 +08:00
// Be sure to put quotes around PATH's value in case any paths have spaces...
std::string new_path("PATH=\"");
<rdar://problem/12462048> LLDB changes argv[0] when debugging a symlink. Now we have the notion of argv0 in the target settings: target.arg0 (string) = There is also the program argument that are separate from the first argument that have existed for a while: target.run-args (arguments) = When running "target create <exe>", we will place the untouched "<exe>" into target.arg0 to ensure when we run, we run with what the user typed. This has been added to the ProcessLaunchInfo and all other needed places so we always carry around the: - resolved executable path - argv0 - program args Some systems may not support separating argv0 from the resolved executable path and the ProcessLaunchInfo needs to carry all of this information along so that each platform can make that decision. llvm-svn: 166137
2012-10-18 06:57:12 +08:00
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;
}
<rdar://problem/13200878> When launching in the shell, make sure if you specify a relative path, and if the current working directory has a space in it, that we don't hose the shell invocation. Currently if we launch with a relative path, we prepend the current working directory to the PATH using: PATH=`cwd`:$PATH a.out ... We needed to add quotes around the value for PATH to make sure if any paths in PATH contained spaces, that we don't hose the shell command. Now we do a: PATH="`cwd`:$PATH" a.out ... llvm-svn: 175135
2013-02-14 11:54:39 +08:00
new_path += "\" ";
<rdar://problem/12462048> LLDB changes argv[0] when debugging a symlink. Now we have the notion of argv0 in the target settings: target.arg0 (string) = There is also the program argument that are separate from the first argument that have existed for a while: target.run-args (arguments) = When running "target create <exe>", we will place the untouched "<exe>" into target.arg0 to ensure when we run, we run with what the user typed. This has been added to the ProcessLaunchInfo and all other needed places so we always carry around the: - resolved executable path - argv0 - program args Some systems may not support separating argv0 from the resolved executable path and the ProcessLaunchInfo needs to carry all of this information along so that each platform can make that decision. llvm-svn: 166137
2012-10-18 06:57:12 +08:00
shell_command.PutCString(new_path.c_str());
}
Added a new host function that allows us to run shell command and get the output from them along with the status and signal: Error Host::RunShellCommand (const char *command, const char *working_dir, int *status_ptr, int *signo_ptr, std::string *command_output_ptr, uint32_t timeout_sec); This will allow us to use this functionality in the host lldb_private::Platform, and also use it in our lldb-platform binary. It leverages the existing code in Host::LaunchProcess and ProcessLaunchInfo. llvm-svn: 154730
2012-04-14 09:42:46 +08:00
shell_command.PutCString ("exec");
<rdar://problem/12462048> LLDB changes argv[0] when debugging a symlink. Now we have the notion of argv0 in the target settings: target.arg0 (string) = There is also the program argument that are separate from the first argument that have existed for a while: target.run-args (arguments) = When running "target create <exe>", we will place the untouched "<exe>" into target.arg0 to ensure when we run, we run with what the user typed. This has been added to the ProcessLaunchInfo and all other needed places so we always carry around the: - resolved executable path - argv0 - program args Some systems may not support separating argv0 from the resolved executable path and the ProcessLaunchInfo needs to carry all of this information along so that each platform can make that decision. llvm-svn: 166137
2012-10-18 06:57:12 +08:00
#if defined(__APPLE__)
// Only Apple supports /usr/bin/arch being able to specify the architecture
Added a new host function that allows us to run shell command and get the output from them along with the status and signal: Error Host::RunShellCommand (const char *command, const char *working_dir, int *status_ptr, int *signo_ptr, std::string *command_output_ptr, uint32_t timeout_sec); This will allow us to use this functionality in the host lldb_private::Platform, and also use it in our lldb-platform binary. It leverages the existing code in Host::LaunchProcess and ProcessLaunchInfo. llvm-svn: 154730
2012-04-14 09:42:46 +08:00
if (GetArchitecture().IsValid())
{
shell_command.Printf(" /usr/bin/arch -arch %s", GetArchitecture().GetArchitectureName());
<rdar://problem/12462048> LLDB changes argv[0] when debugging a symlink. Now we have the notion of argv0 in the target settings: target.arg0 (string) = There is also the program argument that are separate from the first argument that have existed for a while: target.run-args (arguments) = When running "target create <exe>", we will place the untouched "<exe>" into target.arg0 to ensure when we run, we run with what the user typed. This has been added to the ProcessLaunchInfo and all other needed places so we always carry around the: - resolved executable path - argv0 - program args Some systems may not support separating argv0 from the resolved executable path and the ProcessLaunchInfo needs to carry all of this information along so that each platform can make that decision. llvm-svn: 166137
2012-10-18 06:57:12 +08:00
// Set the resume count to 2:
Added a new host function that allows us to run shell command and get the output from them along with the status and signal: Error Host::RunShellCommand (const char *command, const char *working_dir, int *status_ptr, int *signo_ptr, std::string *command_output_ptr, uint32_t timeout_sec); This will allow us to use this functionality in the host lldb_private::Platform, and also use it in our lldb-platform binary. It leverages the existing code in Host::LaunchProcess and ProcessLaunchInfo. llvm-svn: 154730
2012-04-14 09:42:46 +08:00
// 1 - stop in shell
// 2 - stop in /usr/bin/arch
// 3 - then we will stop in our program
SetResumeCount(2);
}
else
{
<rdar://problem/12462048> LLDB changes argv[0] when debugging a symlink. Now we have the notion of argv0 in the target settings: target.arg0 (string) = There is also the program argument that are separate from the first argument that have existed for a while: target.run-args (arguments) = When running "target create <exe>", we will place the untouched "<exe>" into target.arg0 to ensure when we run, we run with what the user typed. This has been added to the ProcessLaunchInfo and all other needed places so we always carry around the: - resolved executable path - argv0 - program args Some systems may not support separating argv0 from the resolved executable path and the ProcessLaunchInfo needs to carry all of this information along so that each platform can make that decision. llvm-svn: 166137
2012-10-18 06:57:12 +08:00
// Set the resume count to 1:
Added a new host function that allows us to run shell command and get the output from them along with the status and signal: Error Host::RunShellCommand (const char *command, const char *working_dir, int *status_ptr, int *signo_ptr, std::string *command_output_ptr, uint32_t timeout_sec); This will allow us to use this functionality in the host lldb_private::Platform, and also use it in our lldb-platform binary. It leverages the existing code in Host::LaunchProcess and ProcessLaunchInfo. llvm-svn: 154730
2012-04-14 09:42:46 +08:00
// 1 - stop in shell
// 2 - then we will stop in our program
SetResumeCount(1);
}
<rdar://problem/12462048> LLDB changes argv[0] when debugging a symlink. Now we have the notion of argv0 in the target settings: target.arg0 (string) = There is also the program argument that are separate from the first argument that have existed for a while: target.run-args (arguments) = When running "target create <exe>", we will place the untouched "<exe>" into target.arg0 to ensure when we run, we run with what the user typed. This has been added to the ProcessLaunchInfo and all other needed places so we always carry around the: - resolved executable path - argv0 - program args Some systems may not support separating argv0 from the resolved executable path and the ProcessLaunchInfo needs to carry all of this information along so that each platform can make that decision. llvm-svn: 166137
2012-10-18 06:57:12 +08:00
#else
// Set the resume count to 1:
// 1 - stop in shell
// 2 - then we will stop in our program
SetResumeCount(1);
#endif
Added a new class to Process.h: ProcessAttachInfo. This class contains enough info for us to attach by pid, or by name and will also allow us to eventually do a lot more powerful attaches. If you look at the options for the "platform process list" command, there are many options which we should be able to specify. This will allow us to do things like "attach to a process named 'tcsh' that has a parent process ID of 123", or "attach to a process named 'x' which has an effective user ID of 345". I finished up the --shell implementation so that it can be used without the --tty option in "process launch". The "--shell" option now can take an optional argument which is the path to the shell to use (or a partial name like "sh" which we will find using the current PATH environment variable). Modified the Process::Attach to use the new ProcessAttachInfo as the sole argument and centralized a lot of code that was in the "process attach" Execute function so that everyone can take advantage of the powerful new attach functionality. llvm-svn: 144615
2011-11-15 11:53:30 +08:00
}
<rdar://problem/12462048> LLDB changes argv[0] when debugging a symlink. Now we have the notion of argv0 in the target settings: target.arg0 (string) = There is also the program argument that are separate from the first argument that have existed for a while: target.run-args (arguments) = When running "target create <exe>", we will place the untouched "<exe>" into target.arg0 to ensure when we run, we run with what the user typed. This has been added to the ProcessLaunchInfo and all other needed places so we always carry around the: - resolved executable path - argv0 - program args Some systems may not support separating argv0 from the resolved executable path and the ProcessLaunchInfo needs to carry all of this information along so that each platform can make that decision. llvm-svn: 166137
2012-10-18 06:57:12 +08:00
if (first_arg_is_full_shell_command)
Added a new class to Process.h: ProcessAttachInfo. This class contains enough info for us to attach by pid, or by name and will also allow us to eventually do a lot more powerful attaches. If you look at the options for the "platform process list" command, there are many options which we should be able to specify. This will allow us to do things like "attach to a process named 'tcsh' that has a parent process ID of 123", or "attach to a process named 'x' which has an effective user ID of 345". I finished up the --shell implementation so that it can be used without the --tty option in "process launch". The "--shell" option now can take an optional argument which is the path to the shell to use (or a partial name like "sh" which we will find using the current PATH environment variable). Modified the Process::Attach to use the new ProcessAttachInfo as the sole argument and centralized a lot of code that was in the "process attach" Execute function so that everyone can take advantage of the powerful new attach functionality. llvm-svn: 144615
2011-11-15 11:53:30 +08:00
{
<rdar://problem/12462048> LLDB changes argv[0] when debugging a symlink. Now we have the notion of argv0 in the target settings: target.arg0 (string) = There is also the program argument that are separate from the first argument that have existed for a while: target.run-args (arguments) = When running "target create <exe>", we will place the untouched "<exe>" into target.arg0 to ensure when we run, we run with what the user typed. This has been added to the ProcessLaunchInfo and all other needed places so we always carry around the: - resolved executable path - argv0 - program args Some systems may not support separating argv0 from the resolved executable path and the ProcessLaunchInfo needs to carry all of this information along so that each platform can make that decision. llvm-svn: 166137
2012-10-18 06:57:12 +08:00
// 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]);
Added a new host function that allows us to run shell command and get the output from them along with the status and signal: Error Host::RunShellCommand (const char *command, const char *working_dir, int *status_ptr, int *signo_ptr, std::string *command_output_ptr, uint32_t timeout_sec); This will allow us to use this functionality in the host lldb_private::Platform, and also use it in our lldb-platform binary. It leverages the existing code in Host::LaunchProcess and ProcessLaunchInfo. llvm-svn: 154730
2012-04-14 09:42:46 +08:00
else
<rdar://problem/12462048> LLDB changes argv[0] when debugging a symlink. Now we have the notion of argv0 in the target settings: target.arg0 (string) = There is also the program argument that are separate from the first argument that have existed for a while: target.run-args (arguments) = When running "target create <exe>", we will place the untouched "<exe>" into target.arg0 to ensure when we run, we run with what the user typed. This has been added to the ProcessLaunchInfo and all other needed places so we always carry around the: - resolved executable path - argv0 - program args Some systems may not support separating argv0 from the resolved executable path and the ProcessLaunchInfo needs to carry all of this information along so that each platform can make that decision. llvm-svn: 166137
2012-10-18 06:57:12 +08:00
return false;
Added a new class to Process.h: ProcessAttachInfo. This class contains enough info for us to attach by pid, or by name and will also allow us to eventually do a lot more powerful attaches. If you look at the options for the "platform process list" command, there are many options which we should be able to specify. This will allow us to do things like "attach to a process named 'tcsh' that has a parent process ID of 123", or "attach to a process named 'x' which has an effective user ID of 345". I finished up the --shell implementation so that it can be used without the --tty option in "process launch". The "--shell" option now can take an optional argument which is the path to the shell to use (or a partial name like "sh" which we will find using the current PATH environment variable). Modified the Process::Attach to use the new ProcessAttachInfo as the sole argument and centralized a lot of code that was in the "process attach" Execute function so that everyone can take advantage of the powerful new attach functionality. llvm-svn: 144615
2011-11-15 11:53:30 +08:00
}
Added a new host function that allows us to run shell command and get the output from them along with the status and signal: Error Host::RunShellCommand (const char *command, const char *working_dir, int *status_ptr, int *signo_ptr, std::string *command_output_ptr, uint32_t timeout_sec); This will allow us to use this functionality in the host lldb_private::Platform, and also use it in our lldb-platform binary. It leverages the existing code in Host::LaunchProcess and ProcessLaunchInfo. llvm-svn: 154730
2012-04-14 09:42:46 +08:00
else
{
<rdar://problem/12462048> LLDB changes argv[0] when debugging a symlink. Now we have the notion of argv0 in the target settings: target.arg0 (string) = There is also the program argument that are separate from the first argument that have existed for a while: target.run-args (arguments) = When running "target create <exe>", we will place the untouched "<exe>" into target.arg0 to ensure when we run, we run with what the user typed. This has been added to the ProcessLaunchInfo and all other needed places so we always carry around the: - resolved executable path - argv0 - program args Some systems may not support separating argv0 from the resolved executable path and the ProcessLaunchInfo needs to carry all of this information along so that each platform can make that decision. llvm-svn: 166137
2012-10-18 06:57:12 +08:00
for (size_t i=0; argv[i] != NULL; ++i)
{
const char *arg = Args::GetShellSafeArgument (argv[i], safe_arg);
shell_command.Printf(" %s", arg);
}
Added a new host function that allows us to run shell command and get the output from them along with the status and signal: Error Host::RunShellCommand (const char *command, const char *working_dir, int *status_ptr, int *signo_ptr, std::string *command_output_ptr, uint32_t timeout_sec); This will allow us to use this functionality in the host lldb_private::Platform, and also use it in our lldb-platform binary. It leverages the existing code in Host::LaunchProcess and ProcessLaunchInfo. llvm-svn: 154730
2012-04-14 09:42:46 +08:00
}
<rdar://problem/12462048> LLDB changes argv[0] when debugging a symlink. Now we have the notion of argv0 in the target settings: target.arg0 (string) = There is also the program argument that are separate from the first argument that have existed for a while: target.run-args (arguments) = When running "target create <exe>", we will place the untouched "<exe>" into target.arg0 to ensure when we run, we run with what the user typed. This has been added to the ProcessLaunchInfo and all other needed places so we always carry around the: - resolved executable path - argv0 - program args Some systems may not support separating argv0 from the resolved executable path and the ProcessLaunchInfo needs to carry all of this information along so that each platform can make that decision. llvm-svn: 166137
2012-10-18 06:57:12 +08:00
shell_arguments.AppendArgument (shell_command.GetString().c_str());
Added a new class to Process.h: ProcessAttachInfo. This class contains enough info for us to attach by pid, or by name and will also allow us to eventually do a lot more powerful attaches. If you look at the options for the "platform process list" command, there are many options which we should be able to specify. This will allow us to do things like "attach to a process named 'tcsh' that has a parent process ID of 123", or "attach to a process named 'x' which has an effective user ID of 345". I finished up the --shell implementation so that it can be used without the --tty option in "process launch". The "--shell" option now can take an optional argument which is the path to the shell to use (or a partial name like "sh" which we will find using the current PATH environment variable). Modified the Process::Attach to use the new ProcessAttachInfo as the sole argument and centralized a lot of code that was in the "process attach" Execute function so that everyone can take advantage of the powerful new attach functionality. llvm-svn: 144615
2011-11-15 11:53:30 +08:00
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)
Added a new class to Process.h: ProcessAttachInfo. This class contains enough info for us to attach by pid, or by name and will also allow us to eventually do a lot more powerful attaches. If you look at the options for the "platform process list" command, there are many options which we should be able to specify. This will allow us to do things like "attach to a process named 'tcsh' that has a parent process ID of 123", or "attach to a process named 'x' which has an effective user ID of 345". I finished up the --shell implementation so that it can be used without the --tty option in "process launch". The "--shell" option now can take an optional argument which is the path to the shell to use (or a partial name like "sh" which we will find using the current PATH environment variable). Modified the Process::Attach to use the new ProcessAttachInfo as the sole argument and centralized a lot of code that was in the "process attach" Execute function so that everyone can take advantage of the powerful new attach functionality. llvm-svn: 144615
2011-11-15 11:53:30 +08:00
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)
Added a new class to Process.h: ProcessAttachInfo. This class contains enough info for us to attach by pid, or by name and will also allow us to eventually do a lot more powerful attaches. If you look at the options for the "platform process list" command, there are many options which we should be able to specify. This will allow us to do things like "attach to a process named 'tcsh' that has a parent process ID of 123", or "attach to a process named 'x' which has an effective user ID of 345". I finished up the --shell implementation so that it can be used without the --tty option in "process launch". The "--shell" option now can take an optional argument which is the path to the shell to use (or a partial name like "sh" which we will find using the current PATH environment variable). Modified the Process::Attach to use the new ProcessAttachInfo as the sole argument and centralized a lot of code that was in the "process attach" Execute function so that everyone can take advantage of the powerful new attach functionality. llvm-svn: 144615
2011-11-15 11:53:30 +08:00
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
Added a new class to Process.h: ProcessAttachInfo. This class contains enough info for us to attach by pid, or by name and will also allow us to eventually do a lot more powerful attaches. If you look at the options for the "platform process list" command, there are many options which we should be able to specify. This will allow us to do things like "attach to a process named 'tcsh' that has a parent process ID of 123", or "attach to a process named 'x' which has an effective user ID of 345". I finished up the --shell implementation so that it can be used without the --tty option in "process launch". The "--shell" option now can take an optional argument which is the path to the shell to use (or a partial name like "sh" which we will find using the current PATH environment variable). Modified the Process::Attach to use the new ProcessAttachInfo as the sole argument and centralized a lot of code that was in the "process attach" Execute function so that everyone can take advantage of the powerful new attach functionality. llvm-svn: 144615
2011-11-15 11:53:30 +08:00
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;
}
bool
ProcessLaunchInfo::FileAction::AddPosixSpawnFileAction (posix_spawn_file_actions_t *file_actions,
const FileAction *info,
Log *log,
Error& error)
{
if (info == NULL)
return false;
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;
Added a new class to Process.h: ProcessAttachInfo. This class contains enough info for us to attach by pid, or by name and will also allow us to eventually do a lot more powerful attaches. If you look at the options for the "platform process list" command, there are many options which we should be able to specify. This will allow us to do things like "attach to a process named 'tcsh' that has a parent process ID of 123", or "attach to a process named 'x' which has an effective user ID of 345". I finished up the --shell implementation so that it can be used without the --tty option in "process launch". The "--shell" option now can take an optional argument which is the path to the shell to use (or a partial name like "sh" which we will find using the current PATH environment variable). Modified the Process::Attach to use the new ProcessAttachInfo as the sole argument and centralized a lot of code that was in the "process attach" Execute function so that everyone can take advantage of the powerful new attach functionality. llvm-svn: 144615
2011-11-15 11:53:30 +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
mode_t mode = 0;
Added a new class to Process.h: ProcessAttachInfo. This class contains enough info for us to attach by pid, or by name and will also allow us to eventually do a lot more powerful attaches. If you look at the options for the "platform process list" command, there are many options which we should be able to specify. This will allow us to do things like "attach to a process named 'tcsh' that has a parent process ID of 123", or "attach to a process named 'x' which has an effective user ID of 345". I finished up the --shell implementation so that it can be used without the --tty option in "process launch". The "--shell" option now can take an optional argument which is the path to the shell to use (or a partial name like "sh" which we will find using the current PATH environment variable). Modified the Process::Attach to use the new ProcessAttachInfo as the sole argument and centralized a lot of code that was in the "process attach" Execute function so that everyone can take advantage of the powerful new attach functionality. llvm-svn: 144615
2011-11-15 11:53:30 +08:00
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();
}
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;
<rdar://problem/12798131> Cleaned up the option parsing code to always pass around the short options as integers. Previously we cast this down to "char" and lost some information. I recently added an assert that would detect duplicate short character options which was firing during the test suite. This fix does the following: - make sure all short options are treated as "int" - make sure that short options can be non-printable values when a short option is not required or when an option group is mixed into many commands and a short option is not desired - fix the help printing to "do the right thing" in all cases. Previously if there were duplicate short character options, it would just not emit help for the duplicates - fix option parsing when there are duplicates to parse options correctly. Previously the option parsing, when done for an OptionGroup, would just start parsing options incorrectly by omitting table entries and it would end up setting the wrong option value llvm-svn: 169189
2012-12-04 08:32:51 +08:00
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;
<rdar://problem/10840355> Fixed STDERR to not be opened as readable. Also cleaned up some of the code that implemented the file actions as some of the code was using the wrong variables, they now use the right ones (in for stdin, out for stdout, err for stderr). llvm-svn: 152102
2012-03-06 12:01:04 +08:00
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;
<rdar://problem/10840355> Fixed STDERR to not be opened as readable. Also cleaned up some of the code that implemented the file actions as some of the code was using the wrong variables, they now use the right ones (in for stdin, out for stdout, err for stderr). llvm-svn: 152102
2012-03-06 12:01:04 +08:00
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;
<rdar://problem/10840355> Fixed STDERR to not be opened as readable. Also cleaned up some of the code that implemented the file actions as some of the code was using the wrong variables, they now use the right ones (in for stdin, out for stdout, err for stderr). llvm-svn: 152102
2012-03-06 12:01:04 +08:00
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;
<rdar://problem/10840355> Fixed STDERR to not be opened as readable. Also cleaned up some of the code that implemented the file actions as some of the code was using the wrong variables, they now use the right ones (in for stdin, out for stdout, err for stderr). llvm-svn: 152102
2012-03-06 12:01:04 +08:00
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;
<rdar://problem/10840355> Fixed STDERR to not be opened as readable. Also cleaned up some of the code that implemented the file actions as some of the code was using the wrong variables, they now use the right ones (in for stdin, out for stdout, err for stderr). llvm-svn: 152102
2012-03-06 12:01:04 +08:00
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;
<rdar://problem/10840355> Fixed STDERR to not be opened as readable. Also cleaned up some of the code that implemented the file actions as some of the code was using the wrong variables, they now use the right ones (in for stdin, out for stdout, err for stderr). llvm-svn: 152102
2012-03-06 12:01:04 +08:00
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;
<rdar://problem/10840355> Fixed STDERR to not be opened as readable. Also cleaned up some of the code that implemented the file actions as some of the code was using the wrong variables, they now use the right ones (in for stdin, out for stdout, err for stderr). llvm-svn: 152102
2012-03-06 12:01:04 +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
case 'p': // Process plug-in name
launch_info.SetProcessPluginName (option_arg);
break;
case 'n': // Disable STDIO
{
ProcessLaunchInfo::FileAction action;
<rdar://problem/10840355> Fixed STDERR to not be opened as readable. Also cleaned up some of the code that implemented the file actions as some of the code was using the wrong variables, they now use the right ones (in for stdin, out for stdout, err for stderr). llvm-svn: 152102
2012-03-06 12:01:04 +08:00
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);
<rdar://problem/10840355> Fixed STDERR to not be opened as readable. Also cleaned up some of the code that implemented the file actions as some of the code was using the wrong variables, they now use the right ones (in for stdin, out for stdout, err for stderr). llvm-svn: 152102
2012-03-06 12:01:04 +08:00
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);
<rdar://problem/10840355> Fixed STDERR to not be opened as readable. Also cleaned up some of the code that implemented the file actions as some of the code was using the wrong variables, they now use the right ones (in for stdin, out for stdout, err for stderr). llvm-svn: 152102
2012-03-06 12:01:04 +08:00
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':
<rdar://problem/11358639> Switch over to the "*-apple-macosx" for desktop and "*-apple-ios" for iOS triples. Also make the selection process for auto selecting platforms based off of an arch much better. llvm-svn: 156354
2012-05-08 09:45:38 +08:00
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;
Modified all Process::Launch() calls to use a ProcessLaunchInfo structure on internal only (public API hasn't changed) to simplify the paramter list to the launch calls down into just one argument. Also all of the argument, envronment and stdio things are now handled in a much more centralized fashion. llvm-svn: 143656
2011-11-04 05:22:33 +08:00
case 'c':
Added a new class to Process.h: ProcessAttachInfo. This class contains enough info for us to attach by pid, or by name and will also allow us to eventually do a lot more powerful attaches. If you look at the options for the "platform process list" command, there are many options which we should be able to specify. This will allow us to do things like "attach to a process named 'tcsh' that has a parent process ID of 123", or "attach to a process named 'x' which has an effective user ID of 345". I finished up the --shell implementation so that it can be used without the --tty option in "process launch". The "--shell" option now can take an optional argument which is the path to the shell to use (or a partial name like "sh" which we will find using the current PATH environment variable). Modified the Process::Attach to use the new ProcessAttachInfo as the sole argument and centralized a lot of code that was in the "process attach" Execute function so that everyone can take advantage of the powerful new attach functionality. llvm-svn: 144615
2011-11-15 11:53:30 +08:00
if (option_arg && option_arg[0])
launch_info.SetShell (option_arg);
else
launch_info.SetShell ("/bin/bash");
Modified all Process::Launch() calls to use a ProcessLaunchInfo structure on internal only (public API hasn't changed) to simplify the paramter list to the launch calls down into just one argument. Also all of the argument, envronment and stdio things are now handled in a much more centralized fashion. llvm-svn: 143656
2011-11-04 05:22:33 +08:00
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:
Cleaned up many error codes. For any who is filling in error strings into lldb_private::Error objects the rules are: - short strings that don't start with a capitol letter unless the name is a class or anything else that is always capitolized - no trailing newline character - should be one line if possible Implemented a first pass at adding "--gdb-format" support to anything that accepts format with optional size/count. llvm-svn: 142999
2011-10-26 08:56:27 +08:00
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[] =
{
{ LLDB_OPT_SET_ALL, false, "stop-at-entry", 's', no_argument, NULL, 0, eArgTypeNone, "Stop at the entry point of the program when launching a process."},
{ LLDB_OPT_SET_ALL, false, "disable-aslr", 'A', no_argument, NULL, 0, eArgTypeNone, "Disable address space layout randomization when launching a process."},
{ LLDB_OPT_SET_ALL, false, "plugin", 'p', required_argument, NULL, 0, eArgTypePlugin, "Name of the process plugin you want to use."},
This is a fix for the command option parser. There was a generic catch-all type for path arguments called "eArgTypePath," and a specialized version called "eArgTypeFilename." It turns out all the cases where we used eArgTypePath we could have used Filename or we explicitly meant a directory. I changed Path to DirectoryName, made it use the directory completer, and rationalized the uses of Path. <rdar://problem/12559915> llvm-svn: 166533
2012-10-24 09:12:14 +08:00
{ LLDB_OPT_SET_ALL, false, "working-dir", 'w', required_argument, NULL, 0, eArgTypeDirectoryName, "Set the current working directory to <path> when running the inferior."},
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
{ LLDB_OPT_SET_ALL, false, "arch", 'a', required_argument, NULL, 0, eArgTypeArchitecture, "Set the architecture for the process to launch when ambiguous."},
{ LLDB_OPT_SET_ALL, false, "environment", 'v', required_argument, NULL, 0, eArgTypeNone, "Specify an environment variable name/value stirng (--environement NAME=VALUE). Can be specified multiple times for subsequent environment entries."},
This is a fix for the command option parser. There was a generic catch-all type for path arguments called "eArgTypePath," and a specialized version called "eArgTypeFilename." It turns out all the cases where we used eArgTypePath we could have used Filename or we explicitly meant a directory. I changed Path to DirectoryName, made it use the directory completer, and rationalized the uses of Path. <rdar://problem/12559915> llvm-svn: 166533
2012-10-24 09:12:14 +08:00
{ LLDB_OPT_SET_ALL, false, "shell", 'c', optional_argument, 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
This is a fix for the command option parser. There was a generic catch-all type for path arguments called "eArgTypePath," and a specialized version called "eArgTypeFilename." It turns out all the cases where we used eArgTypePath we could have used Filename or we explicitly meant a directory. I changed Path to DirectoryName, made it use the directory completer, and rationalized the uses of Path. <rdar://problem/12559915> llvm-svn: 166533
2012-10-24 09:12:14 +08:00
{ LLDB_OPT_SET_1 , false, "stdin", 'i', required_argument, NULL, 0, eArgTypeFilename, "Redirect stdin for the process to <filename>."},
{ LLDB_OPT_SET_1 , false, "stdout", 'o', required_argument, NULL, 0, eArgTypeFilename, "Redirect stdout for the process to <filename>."},
{ LLDB_OPT_SET_1 , false, "stderr", 'e', required_argument, 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
{ LLDB_OPT_SET_2 , false, "tty", 't', no_argument, NULL, 0, eArgTypeNone, "Start the process in a terminal (not supported on all platforms)."},
{ LLDB_OPT_SET_3 , false, "no-stdio", 'n', no_argument, NULL, 0, eArgTypeNone, "Do not set up for terminal I/O to go to running process."},
{ 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() &&
Removed the == and != operators from ArchSpec, since equality can be strict or loose and we want code to explicitly choose one or the other. Also renamed the Compare function to IsEqualTo, to avoid confusion. <rdar://problem/12856749> llvm-svn: 170152
2012-12-14 06:07:14 +08:00
!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;
}
Added memory caching to lldb_private::Process. All lldb_private::Process subclasses will automatically be able to take advantage of caching. The cache line size is set to 512 by default. This greatly speeds up stack backtraces on MacOSX when using the ProcessGDBRemote process plug-in since only about 6300 packets per second can be sent. Initial speedups show: Prior to caching: 10,000 stack frames took 5.2 seconds After caching: 10,000 stack frames in 240 ms! About a 20x speedup! llvm-svn: 122996
2011-01-07 14:08:19 +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
ProcessSP
Process::FindPlugin (Target &target, const char *plugin_name, Listener &listener, const FileSpec *crash_file_path)
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
{
<rdar://problem/13009943> Added a unique integer identifier to processes. Some systems, like JTAG or other simulators, might always assign the same process ID (pid) to the processes that are being debugged. In order for scripts and the APIs to uniquely identify the processes, there needs to be another ID. Now the SBProcess class has: uint32_t SBProcess::GetUniqueID(); This integer ID will help to truly uniquely identify a process and help with appropriate caching that can be associated with a SBProcess object. llvm-svn: 172628
2013-01-17 01:29:04 +08:00
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;
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
ProcessCreateInstance create_callback = NULL;
if (plugin_name)
{
create_callback = PluginManager::GetProcessCreateCallbackForPluginName (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)
{
<rdar://problem/13009943> Added a unique integer identifier to processes. Some systems, like JTAG or other simulators, might always assign the same process ID (pid) to the processes that are being debugged. In order for scripts and the APIs to uniquely identify the processes, there needs to be another ID. Now the SBProcess class has: uint32_t SBProcess::GetUniqueID(); This integer ID will help to truly uniquely identify a process and help with appropriate caching that can be associated with a SBProcess object. llvm-svn: 172628
2013-01-17 01:29:04 +08:00
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();
}
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
}
else
{
Merged Eli Friedman's linux build changes where he added Makefile files that enabled LLVM make style building and made this compile LLDB on Mac OS X. We can now iterate on this to make the build work on both linux and macosx. llvm-svn: 108009
2010-07-10 04:39:50 +08:00
for (uint32_t idx = 0; (create_callback = PluginManager::GetProcessCreateCallbackAtIndex(idx)) != NULL; ++idx)
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +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
process_sp = create_callback(target, listener, crash_file_path);
if (process_sp)
{
<rdar://problem/13009943> Added a unique integer identifier to processes. Some systems, like JTAG or other simulators, might always assign the same process ID (pid) to the processes that are being debugged. In order for scripts and the APIs to uniquely identify the processes, there needs to be another ID. Now the SBProcess class has: uint32_t SBProcess::GetUniqueID(); This integer ID will help to truly uniquely identify a process and help with appropriate caching that can be associated with a SBProcess object. llvm-svn: 172628
2013-01-17 01:29:04 +08:00
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;
<rdar://problem/13009943> Added a unique integer identifier to processes. Some systems, like JTAG or other simulators, might always assign the same process ID (pid) to the processes that are being debugged. In order for scripts and the APIs to uniquely identify the processes, there needs to be another ID. Now the SBProcess class has: uint32_t SBProcess::GetUniqueID(); This integer ID will help to truly uniquely identify a process and help with appropriate caching that can be associated with a SBProcess object. llvm-svn: 172628
2013-01-17 01:29:04 +08:00
}
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
}
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +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;
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
Add a general mechanism to wait on the debugger for Broadcasters of a given class/event bit set. Use this to allow the lldb Driver to emit notifications for breakpoint modifications. <rdar://problem/10619974> llvm-svn: 150665
2012-02-16 14:50:00 +08:00
ConstString &
Process::GetStaticBroadcasterClass ()
{
static ConstString class_name ("lldb.process");
return class_name;
}
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
//----------------------------------------------------------------------
// Process constructor
//----------------------------------------------------------------------
Process::Process(Target &target, Listener &listener) :
Reimplemented the code that backed the "settings" in lldb. There were many issues with the previous implementation: - no setting auto completion - very manual and error prone way of getting/setting variables - tons of code duplication - useless instance names for processes, threads Now settings can easily be defined like option values. The new settings makes use of the "OptionValue" classes so we can re-use the option value code that we use to set settings in command options. No more instances, just "does the right thing". llvm-svn: 162366
2012-08-23 01:17:09 +08:00
ProcessProperties (false),
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
UserID (LLDB_INVALID_PROCESS_ID),
Add a general mechanism to wait on the debugger for Broadcasters of a given class/event bit set. Use this to allow the lldb Driver to emit notifications for breakpoint modifications. <rdar://problem/10619974> llvm-svn: 150665
2012-02-16 14:50:00 +08:00
Broadcaster (&(target.GetDebugger()), "lldb.process"),
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
m_target (target),
m_public_state (eStateUnloaded),
m_private_state (eStateUnloaded),
Add a general mechanism to wait on the debugger for Broadcasters of a given class/event bit set. Use this to allow the lldb Driver to emit notifications for breakpoint modifications. <rdar://problem/10619974> llvm-svn: 150665
2012-02-16 14:50:00 +08:00
m_private_state_broadcaster (NULL, "lldb.process.internal_state_broadcaster"),
m_private_state_control_broadcaster (NULL, "lldb.process.internal_state_control_broadcaster"),
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
m_private_state_listener ("lldb.process.internal_state_listener"),
m_private_state_control_wait(),
m_private_state_thread (LLDB_INVALID_HOST_THREAD),
Move the handling of breakpoint conditions from the Private event loop to the StopInfoBreakpoint::DoActions, which happens as the event is removed. Also use the return value of asynchronous breakpoint callbacks, they get checked before, and override the breakpoint conditions. Added ProcessModInfo class, to unify "stop_id generation" and "memory modification generation", and use where needed. llvm-svn: 137102
2011-08-09 10:12:22 +08:00
m_mod_id (),
<rdar://problem/13009943> Added a unique integer identifier to processes. Some systems, like JTAG or other simulators, might always assign the same process ID (pid) to the processes that are being debugged. In order for scripts and the APIs to uniquely identify the processes, there needs to be another ID. Now the SBProcess class has: uint32_t SBProcess::GetUniqueID(); This integer ID will help to truly uniquely identify a process and help with appropriate caching that can be associated with a SBProcess object. llvm-svn: 172628
2013-01-17 01:29:04 +08:00
m_process_unique_id(0),
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
m_thread_index_id (0),
<rdar://problem/12976225> Checking in the support for doing index ids reservation when given a thread id. llvm-svn: 171904
2013-01-09 06:10:01 +08:00
m_thread_id_to_index_id_map (),
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
m_exit_status (-1),
m_exit_string (),
m_thread_list (this),
m_notifications (),
Fixed Process::Halt() as it was broken for "process halt" after recent changes to the DoHalt down in ProcessGDBRemote. I also moved the functionality that was in ProcessGDBRemote::DoHalt up into Process::Halt so not every class has to implement a tricky halt/resume on the internal state thread. The functionality is the same as it was before with two changes: - when we eat the event we now just reuse the event we consume when the private state thread is paused and set the interrupted bool on the event if needed - we also properly update the Process::m_public_state with the state of the event we consume. Prior to this, if you issued a "process halt" it would eat the event, not update the process state, and then produce a new event with the interrupted bit set and send it. Anyone listening to the event would get the stopped event with a process that whose state was set to "running". Fixed debugserver to not have to be spawned with the architecture of the inferior process. This worked fine for launching processes, but when attaching to processes by name or pid without a file in lldb, it would fail. Now debugserver can support multiple architectures for a native debug session on the current host. This currently means i386 and x86_64 are supported in the same binary and a x86_64 debugserver can attach to a i386 executable. This change involved a lot of changes to make sure we dynamically detect the correct registers for the inferior process. llvm-svn: 119680
2010-11-18 13:57:03 +08:00
m_image_tokens (),
m_listener (listener),
m_breakpoint_site_list (),
m_dynamic_checkers_ap (),
Make processes use InputReaders for their input. Move the process ReadThread stuff into the main Process class (out of the Process Plugins). This has the (intended) side effect of disabling the command line tool from reading input/commands while the process is running (the input is directed to the running process rather than to the command interpreter). llvm-svn: 119329
2010-11-16 13:07:41 +08:00
m_unix_signals (),
Fixed Process::Halt() as it was broken for "process halt" after recent changes to the DoHalt down in ProcessGDBRemote. I also moved the functionality that was in ProcessGDBRemote::DoHalt up into Process::Halt so not every class has to implement a tricky halt/resume on the internal state thread. The functionality is the same as it was before with two changes: - when we eat the event we now just reuse the event we consume when the private state thread is paused and set the interrupted bool on the event if needed - we also properly update the Process::m_public_state with the state of the event we consume. Prior to this, if you issued a "process halt" it would eat the event, not update the process state, and then produce a new event with the interrupted bit set and send it. Anyone listening to the event would get the stopped event with a process that whose state was set to "running". Fixed debugserver to not have to be spawned with the architecture of the inferior process. This worked fine for launching processes, but when attaching to processes by name or pid without a file in lldb, it would fail. Now debugserver can support multiple architectures for a native debug session on the current host. This currently means i386 and x86_64 are supported in the same binary and a x86_64 debugserver can attach to a i386 executable. This change involved a lot of changes to make sure we dynamically detect the correct registers for the inferior process. llvm-svn: 119680
2010-11-18 13:57:03 +08:00
m_abi_sp (),
Make processes use InputReaders for their input. Move the process ReadThread stuff into the main Process class (out of the Process Plugins). This has the (intended) side effect of disabling the command line tool from reading input/commands while the process is running (the input is directed to the running process rather than to the command interpreter). llvm-svn: 119329
2010-11-16 13:07:41 +08:00
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"),
Fixed Process::Halt() as it was broken for "process halt" after recent changes to the DoHalt down in ProcessGDBRemote. I also moved the functionality that was in ProcessGDBRemote::DoHalt up into Process::Halt so not every class has to implement a tricky halt/resume on the internal state thread. The functionality is the same as it was before with two changes: - when we eat the event we now just reuse the event we consume when the private state thread is paused and set the interrupted bool on the event if needed - we also properly update the Process::m_public_state with the state of the event we consume. Prior to this, if you issued a "process halt" it would eat the event, not update the process state, and then produce a new event with the interrupted bit set and send it. Anyone listening to the event would get the stopped event with a process that whose state was set to "running". Fixed debugserver to not have to be spawned with the architecture of the inferior process. This worked fine for launching processes, but when attaching to processes by name or pid without a file in lldb, it would fail. Now debugserver can support multiple architectures for a native debug session on the current host. This currently means i386 and x86_64 are supported in the same binary and a x86_64 debugserver can attach to a i386 executable. This change involved a lot of changes to make sure we dynamically detect the correct registers for the inferior process. llvm-svn: 119680
2010-11-18 13:57:03 +08:00
m_stdio_communication_mutex (Mutex::eMutexTypeRecursive),
Added memory caching to lldb_private::Process. All lldb_private::Process subclasses will automatically be able to take advantage of caching. The cache line size is set to 512 by default. This greatly speeds up stack backtraces on MacOSX when using the ProcessGDBRemote process plug-in since only about 6300 packets per second can be sent. Initial speedups show: Prior to caching: 10,000 stack frames took 5.2 seconds After caching: 10,000 stack frames in 240 ms! About a 20x speedup! llvm-svn: 122996
2011-01-07 14:08:19 +08:00
m_stdout_data (),
<rdar://problem/10103980> A long time ago we started to centralized the STDOUT in lldb_private::Process but we missed a few things still in ProcessGDBRemote. llvm-svn: 144491
2011-11-13 12:45:22 +08:00
m_stderr_data (),
<rdar://problem/12720514> Sub-TLF: Provide service to profile the inferior This allows client to query profiling states on the inferior. llvm-svn: 168228
2012-11-17 08:21:04 +08:00
m_profile_data_comm_mutex (Mutex::eMutexTypeRecursive),
m_profile_data (),
Added an allocated memory cache to avoid having to allocate memory over and over when running JITed expressions. The allocated memory cache will cache allocate memory a page at a time for each permission combination and divvy up the memory and hand it out in 16 byte increments. llvm-svn: 131453
2011-05-17 11:37:42 +08:00
m_memory_cache (*this),
m_allocated_memory_cache (*this),
Fixed the issue that was causing our monitor process threads to crash, it turned out to be unitialized data in the ProcessLaunchInfo default constructor. Turning on MallocScribble in the environment helped track this down. When we launch and attach using the host layer, we now inform the process that it shouldn't detach when by calling an accessor. llvm-svn: 144882
2011-11-17 12:46:02 +08:00
m_should_detach (false),
Fixed a problem where expressions would attempt to allocate memory in a process that did not support expression execution. Also improved detection of whether or not a process can execute expressions. llvm-svn: 140202
2011-09-21 07:01:51 +08:00
m_next_event_action_ap(),
Order ivar initializers to how they're declared in the class. llvm-svn: 154147
2012-04-06 08:10:21 +08:00
m_run_lock (),
Make sure that when if we are going to Halt while the process is in the middle of HandlePrivateEvent we wait till that is done. We need a stronger way to do this, but in practice this works and using some locking strategy is harder because Halt & HandlePrivateEvent generally happen on different threads. llvm-svn: 158042
2012-06-06 08:29:30 +08:00
m_currently_handling_event(false),
Rework how the API mutex is acquired when filling out an ExecutionContext from an ExecutionContextRef, particularly in the SBThread & SBFrame interfaces. Instead of filling the whole context & then getting the API mutex, we now get only the target, acquire the API mutex from it, then fill out the rest of the context. This removes a race condition where you get a ThreadSP, then wait on the API mutex while another command Destroy's the Thread you've just gotten. Also fixed the ExecutionContextRef::Get*SP calls so they don't return invalid objects. Also fixed the ExecutionContext::Has*Scope calls so they don't claim to have a scope if the object representing that scope has been destroyed. Also fixed a think-o in Thread::IsValid which was causing it to return the opposite of the desired value. <rdar://problem/11995490> llvm-svn: 162401
2012-08-23 05:34:33 +08:00
m_finalize_called(false),
Reworked the way Process::RunThreadPlan and the ThreadPlanCallFunction interoperate to fix problems where hitting auto-continue signals while running a thread plan would cause us to lose control of the debug session. <rdar://problem/12993641> llvm-svn: 174793
2013-02-09 09:29:05 +08:00
m_last_broadcast_state (eStateInvalid),
Fix ivar ordering for Process ctor to match the order they're declared in the .h file. llvm-svn: 176473
2013-03-05 11:33:59 +08:00
m_destroy_in_process (false),
m_can_jit(eCanJITDontKnow)
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
{
Add a general mechanism to wait on the debugger for Broadcasters of a given class/event bit set. Use this to allow the lldb Driver to emit notifications for breakpoint modifications. <rdar://problem/10619974> llvm-svn: 150665
2012-02-16 14:50:00 +08:00
CheckInWithManager ();
Create more useful instance names for target, process and thread instances. Change default 'set' behavior so that all instance settings for the specified variable will be updated, unless the "-n" ("--no_override") command options is specified. llvm-svn: 114808
2010-09-27 08:30:10 +08:00
<rdar://problem/13521159> LLDB is crashing when logging is enabled from lldb-perf-clang. This has to do with the global destructor chain as the process and its threads are being torn down. All logging channels now make one and only one instance that is kept in a global pointer which is never freed. This guarantees that logging can correctly continue as the process tears itself down. llvm-svn: 178191
2013-03-28 07:08:40 +08:00
Log *log(lldb_private::GetLogIfAllCategoriesSet (LIBLLDB_LOG_OBJECT));
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
if (log)
log->Printf ("%p Process::Process()", this);
Cleaned up the API logging a lot more to reduce redundant information and keep the file size a bit smaller. Exposed SBValue::GetExpressionPath() so SBValue users can get an expression path for their values. llvm-svn: 117851
2010-10-31 11:01:06 +08:00
SetEventName (eBroadcastBitStateChanged, "state-changed");
SetEventName (eBroadcastBitInterrupt, "interrupt");
SetEventName (eBroadcastBitSTDOUT, "stdout-available");
SetEventName (eBroadcastBitSTDERR, "stderr-available");
<rdar://problem/12720514> Sub-TLF: Provide service to profile the inferior This allows client to query profiling states on the inferior. llvm-svn: 168228
2012-11-17 08:21:04 +08:00
SetEventName (eBroadcastBitProfileData, "profile-data-available");
Cleaned up the API logging a lot more to reduce redundant information and keep the file size a bit smaller. Exposed SBValue::GetExpressionPath() so SBValue users can get an expression path for their values. llvm-svn: 117851
2010-10-31 11:01:06 +08:00
<rdar://problem/12500785> I tracked down a leak that could happen when detaching from a process where the lldb_private::Process objects would stay around forever. This was caused by a eStateDetached event that was queued up on the lldb_private::Process private state thread listener. Since process events contain shared pointers to the process, this is dangerous if they don't get consume or cleared as having the lldb_private::Process class contain a collection of things that have a shared pointer to yourself is obviously bad. To fix this I modified the Process::Finalize() function to clear this list. The actual thing that was holding onto the ModuleSP and thus the static archive, was a stack frame. Since the process wasn't going away, it still had thread objects and they still had frames. I modified the Thread::Destroy() to clear the stack frames to ensure this further doesn't happen. llvm-svn: 166964
2012-10-30 04:52:08 +08:00
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");
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
listener.StartListeningForEvents (this,
eBroadcastBitStateChanged |
eBroadcastBitInterrupt |
eBroadcastBitSTDOUT |
<rdar://problem/12720514> Sub-TLF: Provide service to profile the inferior This allows client to query profiling states on the inferior. llvm-svn: 168228
2012-11-17 08:21:04 +08:00
eBroadcastBitSTDERR |
eBroadcastBitProfileData);
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
m_private_state_listener.StartListeningForEvents(&m_private_state_broadcaster,
Added an lldb_private & equivalent SB API to send an AsyncInterrupt to the event loop. Convert from calling Halt in the lldb Driver.cpp's input reader's sigint handler to sending this AsyncInterrupt so it can be handled in the event loop. If you are attaching and get an async interrupt, abort the attach attempt. Also remember to destroy the process if get interrupted while attaching. Getting this to work also required handing the eBroadcastBitInterrupt in a few more places in Process WaitForEvent & friends. <rdar://problem/10792425> llvm-svn: 160903
2012-07-28 07:57:19 +08:00
eBroadcastBitStateChanged |
eBroadcastBitInterrupt);
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
m_private_state_listener.StartListeningForEvents(&m_private_state_control_broadcaster,
eBroadcastInternalStateControlStop |
eBroadcastInternalStateControlPause |
eBroadcastInternalStateControlResume);
}
//----------------------------------------------------------------------
// Destructor
//----------------------------------------------------------------------
Process::~Process()
{
<rdar://problem/13521159> LLDB is crashing when logging is enabled from lldb-perf-clang. This has to do with the global destructor chain as the process and its threads are being torn down. All logging channels now make one and only one instance that is kept in a global pointer which is never freed. This guarantees that logging can correctly continue as the process tears itself down. llvm-svn: 178191
2013-03-28 07:08:40 +08:00
Log *log(lldb_private::GetLogIfAllCategoriesSet (LIBLLDB_LOG_OBJECT));
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
if (log)
log->Printf ("%p Process::~Process()", this);
StopPrivateStateThread();
}
Reimplemented the code that backed the "settings" in lldb. There were many issues with the previous implementation: - no setting auto completion - very manual and error prone way of getting/setting variables - tons of code duplication - useless instance names for processes, threads Now settings can easily be defined like option values. The new settings makes use of the "OptionValue" classes so we can re-use the option value code that we use to set settings in command options. No more instances, just "does the right thing". llvm-svn: 162366
2012-08-23 01:17:09 +08:00
const ProcessPropertiesSP &
Process::GetGlobalProperties()
{
static ProcessPropertiesSP g_settings_sp;
if (!g_settings_sp)
g_settings_sp.reset (new ProcessProperties (true));
return g_settings_sp;
}
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
void
Process::Finalize()
{
Fixed the issue that was causing our monitor process threads to crash, it turned out to be unitialized data in the ProcessLaunchInfo default constructor. Turning on MallocScribble in the environment helped track this down. When we launch and attach using the host layer, we now inform the process that it shouldn't detach when by calling an accessor. llvm-svn: 144882
2011-11-17 12:46:02 +08:00
switch (GetPrivateState())
{
case eStateConnected:
case eStateAttaching:
case eStateLaunching:
case eStateStopped:
case eStateRunning:
case eStateStepping:
case eStateCrashed:
case eStateSuspended:
if (GetShouldDetach())
Detach();
else
Destroy();
break;
case eStateInvalid:
case eStateUnloaded:
case eStateDetached:
case eStateExited:
break;
}
Cleaned up the the code that figures out the inlined stack frames given a symbol context that represents an inlined function. This function has been renamed internally to: bool SymbolContext::GetParentOfInlinedScope (const Address &curr_frame_pc, SymbolContext &next_frame_sc, Address &next_frame_pc) const; And externally to: SBSymbolContext SBSymbolContext::GetParentOfInlinedScope (const SBAddress &curr_frame_pc, SBAddress &parent_frame_addr) const; The correct blocks are now correctly calculated. Switched the stack backtracing engine (in StackFrameList) and the address context printing over to using the internal SymbolContext::GetParentOfInlinedScope(...) so all inlined callstacks will match exactly. llvm-svn: 140910
2011-10-01 08:45:15 +08:00
// Clear our broadcaster before we proceed with destroying
Broadcaster::Clear();
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
// Do any cleanup needed prior to being destructed... Subclasses
// that override this method should call this superclass method as well.
Destroy the dynamic loader plugin in Process::Finalize. If you wait till the auto_ptr gets deleted in the normal course of things the real process class will have been destroyed already, and it's hard to shut down the dynamic loader without accessing some process pure virtual method. llvm-svn: 125668
2011-02-17 01:54:55 +08:00
// 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.
<rdar://problem/10732738> Release more stuff in Process::Destroy(). llvm-svn: 148597
2012-01-21 07:08:34 +08:00
m_dynamic_checkers_ap.reset();
m_abi_sp.reset();
Added a new plug-in type: lldb_private::OperatingSystem. The operating system plug-ins are add on plug-ins for the lldb_private::Process class that can add thread contexts that are read from memory. It is common in kernels to have a lot of threads that are not currently executing on any cores (JTAG debugging also follows this sort of thing) and are context switched out whose state is stored in memory data structures. Clients can now subclass the OperatingSystem plug-ins and then make sure their Create functions correcltly only enable themselves when the right binary/target triple are being debugged. The operating system plug-ins get a chance to attach themselves to processes just after launching or attaching and are given a lldb_private::Process object pointer which can be inspected to see if the main executable, target triple, or any shared libraries match a case where the OS plug-in should be used. Currently the OS plug-ins can create new threads, define the register contexts for these threads (which can all be different if desired), and populate and manage the thread info (stop reason, registers in the register context) as the debug session goes on. llvm-svn: 138228
2011-08-22 10:49:39 +08:00
m_os_ap.reset();
<rdar://problem/10732738> Release more stuff in Process::Destroy(). llvm-svn: 148597
2012-01-21 07:08:34 +08:00
m_dyld_ap.reset();
Switching back to using std::tr1::shared_ptr. We originally switched away due to RTTI worries since llvm and clang don't use RTTI, but I was able to switch back with no issues as far as I can tell. Once the RTTI issue wasn't an issue, we were looking for a way to properly track weak pointers to objects to solve some of the threading issues we have been running into which naturally led us back to std::tr1::weak_ptr. We also wanted the ability to make a shared pointer from just a pointer, which is also easily solved using the std::tr1::enable_shared_from_this class. The main reason for this move back is so we can start properly having weak references to objects. Currently a lldb_private::Thread class has a refrence to its parent lldb_private::Process. This doesn't work well when we now hand out a SBThread object that contains a shared pointer to a lldb_private::Thread as this SBThread can be held onto by external clients and if they end up using one of these objects we can easily crash. So the next task is to start adopting std::tr1::weak_ptr where ever it makes sense which we can do with lldb_private::Debugger, lldb_private::Target, lldb_private::Process, lldb_private::Thread, lldb_private::StackFrame, and many more objects now that they are no longer using intrusive ref counted pointer objects (you can't do std::tr1::weak_ptr functionality with intrusive pointers). llvm-svn: 149207
2012-01-30 04:56:30 +08:00
m_thread_list.Destroy();
<rdar://problem/10732738> Release more stuff in Process::Destroy(). llvm-svn: 148597
2012-01-21 07:08:34 +08:00
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();
<rdar://problem/12500785> I tracked down a leak that could happen when detaching from a process where the lldb_private::Process objects would stay around forever. This was caused by a eStateDetached event that was queued up on the lldb_private::Process private state thread listener. Since process events contain shared pointers to the process, this is dangerous if they don't get consume or cleared as having the lldb_private::Process class contain a collection of things that have a shared pointer to yourself is obviously bad. To fix this I modified the Process::Finalize() function to clear this list. The actual thing that was holding onto the ModuleSP and thus the static archive, was a stack frame. Since the process wasn't going away, it still had thread objects and they still had frames. I modified the Thread::Destroy() to clear the stack frames to ensure this further doesn't happen. llvm-svn: 166964
2012-10-30 04:52:08 +08:00
//#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();
Rework how the API mutex is acquired when filling out an ExecutionContext from an ExecutionContextRef, particularly in the SBThread & SBFrame interfaces. Instead of filling the whole context & then getting the API mutex, we now get only the target, acquire the API mutex from it, then fill out the rest of the context. This removes a race condition where you get a ThreadSP, then wait on the API mutex while another command Destroy's the Thread you've just gotten. Also fixed the ExecutionContextRef::Get*SP calls so they don't return invalid objects. Also fixed the ExecutionContext::Has*Scope calls so they don't claim to have a scope if the object representing that scope has been destroyed. Also fixed a think-o in Thread::IsValid which was causing it to return the opposite of the desired value. <rdar://problem/11995490> llvm-svn: 162401
2012-08-23 05:34:33 +08:00
m_finalize_called = true;
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
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
<rdar://problem/11935492> Fixed an issue where if we call "Process::Destroy()" and the process is running, if we try to stop it and get "exited" back as the stop reason, we will still deliver the exited event. llvm-svn: 163591
2012-09-11 10:33:37 +08:00
Process::WaitForProcessToStop (const TimeValue *timeout, lldb::EventSP *event_sp_ptr)
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
{
Move the handling of breakpoint conditions from the Private event loop to the StopInfoBreakpoint::DoActions, which happens as the event is removed. Also use the return value of asynchronous breakpoint callbacks, they get checked before, and override the breakpoint conditions. Added ProcessModInfo class, to unify "stop_id generation" and "memory modification generation", and use where needed. llvm-svn: 137102
2011-08-09 10:12:22 +08:00
// 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.
<rdar://problem/11935492> Fixed an issue where if we call "Process::Destroy()" and the process is running, if we try to stop it and get "exited" back as the stop reason, we will still deliver the exited event. llvm-svn: 163591
2012-09-11 10:33:37 +08:00
if (event_sp_ptr)
event_sp_ptr->reset();
Move the handling of breakpoint conditions from the Private event loop to the StopInfoBreakpoint::DoActions, which happens as the event is removed. Also use the return value of asynchronous breakpoint callbacks, they get checked before, and override the breakpoint conditions. Added ProcessModInfo class, to unify "stop_id generation" and "memory modification generation", and use where needed. llvm-svn: 137102
2011-08-09 10:12:22 +08:00
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;
while (state != eStateInvalid)
{
<rdar://problem/11935492> Fixed an issue where if we call "Process::Destroy()" and the process is running, if we try to stop it and get "exited" back as the stop reason, we will still deliver the exited event. llvm-svn: 163591
2012-09-11 10:33:37 +08:00
EventSP event_sp;
Move the handling of breakpoint conditions from the Private event loop to the StopInfoBreakpoint::DoActions, which happens as the event is removed. Also use the return value of asynchronous breakpoint callbacks, they get checked before, and override the breakpoint conditions. Added ProcessModInfo class, to unify "stop_id generation" and "memory modification generation", and use where needed. llvm-svn: 137102
2011-08-09 10:12:22 +08:00
state = WaitForStateChangedEvents (timeout, event_sp);
<rdar://problem/11935492> Fixed an issue where if we call "Process::Destroy()" and the process is running, if we try to stop it and get "exited" back as the stop reason, we will still deliver the exited event. llvm-svn: 163591
2012-09-11 10:33:37 +08:00
if (event_sp_ptr && event_sp)
*event_sp_ptr = event_sp;
Move the handling of breakpoint conditions from the Private event loop to the StopInfoBreakpoint::DoActions, which happens as the event is removed. Also use the return value of asynchronous breakpoint callbacks, they get checked before, and override the breakpoint conditions. Added ProcessModInfo class, to unify "stop_id generation" and "memory modification generation", and use where needed. llvm-svn: 137102
2011-08-09 10:12:22 +08:00
switch (state)
{
case eStateCrashed:
case eStateDetached:
case eStateExited:
case eStateUnloaded:
return state;
case eStateStopped:
if (Process::ProcessEventData::GetRestartedFromEvent(event_sp.get()))
continue;
else
return state;
default:
continue;
}
}
return state;
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
StateType
Process::WaitForState
(
const TimeValue *timeout,
const StateType *match_states, const uint32_t num_match_states
)
{
EventSP event_sp;
uint32_t i;
Cleaned up the SWIG stuff so all includes happen as they should, no pulling tricks to get types to resolve. I did this by correctly including the correct files: stdint.h and all lldb-*.h files first before including the API files. This allowed me to remove all of the hacks that were in the lldb.swig file and it also allows all of the #defines in lldb-defines.h and enumerations in lldb-enumerations.h to appear in the lldb.py module. This will make the python script code a lot more readable. Cleaned up the "process launch" command to not execute a "process continue" command, it now just does what it should have with the internal API calls instead of executing another command line command. Made the lldb_private::Process set the state to launching and attaching if WillLaunch/WillAttach return no error respectively. llvm-svn: 115902
2010-10-07 12:19:01 +08:00
StateType state = GetState();
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
while (state != eStateInvalid)
{
Cleaned up the SWIG stuff so all includes happen as they should, no pulling tricks to get types to resolve. I did this by correctly including the correct files: stdint.h and all lldb-*.h files first before including the API files. This allowed me to remove all of the hacks that were in the lldb.swig file and it also allows all of the #defines in lldb-defines.h and enumerations in lldb-enumerations.h to appear in the lldb.py module. This will make the python script code a lot more readable. Cleaned up the "process launch" command to not execute a "process continue" command, it now just does what it should have with the internal API calls instead of executing another command line command. Made the lldb_private::Process set the state to launching and attaching if WillLaunch/WillAttach return no error respectively. llvm-svn: 115902
2010-10-07 12:19:01 +08:00
// If we are exited or detached, we won't ever get back to any
// other valid state...
if (state == eStateDetached || state == eStateExited)
return state;
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
state = WaitForStateChangedEvents (timeout, event_sp);
for (i=0; i<num_match_states; ++i)
{
if (match_states[i] == state)
return state;
}
}
return state;
}
Add a way to temporarily divert events from a broadcaster to a private listener. llvm-svn: 116271
2010-10-12 07:53:14 +08:00
bool
Process::HijackProcessEvents (Listener *listener)
{
if (listener != NULL)
{
Added an lldb_private & equivalent SB API to send an AsyncInterrupt to the event loop. Convert from calling Halt in the lldb Driver.cpp's input reader's sigint handler to sending this AsyncInterrupt so it can be handled in the event loop. If you are attaching and get an async interrupt, abort the attach attempt. Also remember to destroy the process if get interrupted while attaching. Getting this to work also required handing the eBroadcastBitInterrupt in a few more places in Process WaitForEvent & friends. <rdar://problem/10792425> llvm-svn: 160903
2012-07-28 07:57:19 +08:00
return HijackBroadcaster(listener, eBroadcastBitStateChanged | eBroadcastBitInterrupt);
Add a way to temporarily divert events from a broadcaster to a private listener. llvm-svn: 116271
2010-10-12 07:53:14 +08:00
}
else
return false;
}
void
Process::RestoreProcessEvents ()
{
RestoreBroadcaster();
}
Rework the RunThreadPlan event handling to use Event Hijacking not stopping the event thread. Also clarify the logic of the function. llvm-svn: 125083
2011-02-08 13:20:59 +08:00
bool
Process::HijackPrivateProcessEvents (Listener *listener)
{
if (listener != NULL)
{
Added an lldb_private & equivalent SB API to send an AsyncInterrupt to the event loop. Convert from calling Halt in the lldb Driver.cpp's input reader's sigint handler to sending this AsyncInterrupt so it can be handled in the event loop. If you are attaching and get an async interrupt, abort the attach attempt. Also remember to destroy the process if get interrupted while attaching. Getting this to work also required handing the eBroadcastBitInterrupt in a few more places in Process WaitForEvent & friends. <rdar://problem/10792425> llvm-svn: 160903
2012-07-28 07:57:19 +08:00
return m_private_state_broadcaster.HijackBroadcaster(listener, eBroadcastBitStateChanged | eBroadcastBitInterrupt);
Rework the RunThreadPlan event handling to use Event Hijacking not stopping the event thread. Also clarify the logic of the function. llvm-svn: 125083
2011-02-08 13:20:59 +08:00
}
else
return false;
}
void
Process::RestorePrivateProcessEvents ()
{
m_private_state_broadcaster.RestoreBroadcaster();
}
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
StateType
Process::WaitForStateChangedEvents (const TimeValue *timeout, EventSP &event_sp)
{
<rdar://problem/13521159> LLDB is crashing when logging is enabled from lldb-perf-clang. This has to do with the global destructor chain as the process and its threads are being torn down. All logging channels now make one and only one instance that is kept in a global pointer which is never freed. This guarantees that logging can correctly continue as the process tears itself down. llvm-svn: 178191
2013-03-28 07:08:40 +08:00
Log *log(lldb_private::GetLogIfAllCategoriesSet (LIBLLDB_LOG_PROCESS));
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
if (log)
log->Printf ("Process::%s (timeout = %p, event_sp)...", __FUNCTION__, timeout);
StateType state = eStateInvalid;
Stop the driver from handling SIGPIPE in case we communicate with stale sockets so the driver doesn't just crash. Added support for connecting to named sockets (unix IPC sockets) in ConnectionFileDescriptor. Modified the Host::LaunchInNewTerminal() for MacOSX to return the process ID of the inferior process instead of the process ID of the Terminal.app. This was done by modifying the "darwin-debug" executable to connect to lldb through a named unix socket which is passed down as an argument. This allows a quick handshake between "lldb" and "darwin-debug" so we can get the process ID of the inferior and then attach by process ID and avoid attaching to the inferior by process name since there could be more than one process with that name. This still has possible race conditions, those will be fixed in the near future. This fixes the SIGPIPE issues that were sometimes being seen when task_for_pid was failing. llvm-svn: 116792
2010-10-19 11:25:40 +08:00
if (m_listener.WaitForEventForBroadcasterWithType (timeout,
this,
Added an lldb_private & equivalent SB API to send an AsyncInterrupt to the event loop. Convert from calling Halt in the lldb Driver.cpp's input reader's sigint handler to sending this AsyncInterrupt so it can be handled in the event loop. If you are attaching and get an async interrupt, abort the attach attempt. Also remember to destroy the process if get interrupted while attaching. Getting this to work also required handing the eBroadcastBitInterrupt in a few more places in Process WaitForEvent & friends. <rdar://problem/10792425> llvm-svn: 160903
2012-07-28 07:57:19 +08:00
eBroadcastBitStateChanged | eBroadcastBitInterrupt,
Stop the driver from handling SIGPIPE in case we communicate with stale sockets so the driver doesn't just crash. Added support for connecting to named sockets (unix IPC sockets) in ConnectionFileDescriptor. Modified the Host::LaunchInNewTerminal() for MacOSX to return the process ID of the inferior process instead of the process ID of the Terminal.app. This was done by modifying the "darwin-debug" executable to connect to lldb through a named unix socket which is passed down as an argument. This allows a quick handshake between "lldb" and "darwin-debug" so we can get the process ID of the inferior and then attach by process ID and avoid attaching to the inferior by process name since there could be more than one process with that name. This still has possible race conditions, those will be fixed in the near future. This fixes the SIGPIPE issues that were sometimes being seen when task_for_pid was failing. llvm-svn: 116792
2010-10-19 11:25:40 +08:00
event_sp))
Added an lldb_private & equivalent SB API to send an AsyncInterrupt to the event loop. Convert from calling Halt in the lldb Driver.cpp's input reader's sigint handler to sending this AsyncInterrupt so it can be handled in the event loop. If you are attaching and get an async interrupt, abort the attach attempt. Also remember to destroy the process if get interrupted while attaching. Getting this to work also required handing the eBroadcastBitInterrupt in a few more places in Process WaitForEvent & friends. <rdar://problem/10792425> llvm-svn: 160903
2012-07-28 07:57:19 +08:00
{
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__);
}
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
if (log)
log->Printf ("Process::%s (timeout = %p, event_sp) => %s",
__FUNCTION__,
timeout,
StateAsCString(state));
return state;
}
Event *
Process::PeekAtStateChangedEvents ()
{
<rdar://problem/13521159> LLDB is crashing when logging is enabled from lldb-perf-clang. This has to do with the global destructor chain as the process and its threads are being torn down. All logging channels now make one and only one instance that is kept in a global pointer which is never freed. This guarantees that logging can correctly continue as the process tears itself down. llvm-svn: 178191
2013-03-28 07:08:40 +08:00
Log *log(lldb_private::GetLogIfAllCategoriesSet (LIBLLDB_LOG_PROCESS));
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
if (log)
log->Printf ("Process::%s...", __FUNCTION__);
Event *event_ptr;
Stop the driver from handling SIGPIPE in case we communicate with stale sockets so the driver doesn't just crash. Added support for connecting to named sockets (unix IPC sockets) in ConnectionFileDescriptor. Modified the Host::LaunchInNewTerminal() for MacOSX to return the process ID of the inferior process instead of the process ID of the Terminal.app. This was done by modifying the "darwin-debug" executable to connect to lldb through a named unix socket which is passed down as an argument. This allows a quick handshake between "lldb" and "darwin-debug" so we can get the process ID of the inferior and then attach by process ID and avoid attaching to the inferior by process name since there could be more than one process with that name. This still has possible race conditions, those will be fixed in the near future. This fixes the SIGPIPE issues that were sometimes being seen when task_for_pid was failing. llvm-svn: 116792
2010-10-19 11:25:40 +08:00
event_ptr = m_listener.PeekAtNextEventForBroadcasterWithType (this,
eBroadcastBitStateChanged);
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
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)
{
<rdar://problem/13521159> LLDB is crashing when logging is enabled from lldb-perf-clang. This has to do with the global destructor chain as the process and its threads are being torn down. All logging channels now make one and only one instance that is kept in a global pointer which is never freed. This guarantees that logging can correctly continue as the process tears itself down. llvm-svn: 178191
2013-03-28 07:08:40 +08:00
Log *log(lldb_private::GetLogIfAllCategoriesSet (LIBLLDB_LOG_PROCESS));
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
if (log)
log->Printf ("Process::%s (timeout = %p, event_sp)...", __FUNCTION__, timeout);
StateType state = eStateInvalid;
Fixed an issue in "SBError SBProcess::Destroy ()" where it wasn't properly checking the validity of the shared pointer prior to using it. Fixed the GDB remote plug-in to once again watch for a reply from the "k" packet, and fixed the logic to make sure the thread requesting the kill and the async thread play nice (and very quickly) by synchronizing the packet sending and reply. I also tweaked some of the shut down packet ("k" kill, "D" detach, and the halt packet) to make sure they do the right thing. Fixed "StateType Process::WaitForProcessStopPrivate (...)" to correctly pass the timeout along to WaitForStateChangedEventsPrivate() and made the function behave correctly with respect to timing out. Added separate STDIN, STDOUT, and STDERR support to debugserver. Also added the start of being able to set the working directory for the inferior process. llvm-svn: 124049
2011-01-23 07:43:18 +08:00
if (m_private_state_listener.WaitForEventForBroadcasterWithType (timeout,
&m_private_state_broadcaster,
Added an lldb_private & equivalent SB API to send an AsyncInterrupt to the event loop. Convert from calling Halt in the lldb Driver.cpp's input reader's sigint handler to sending this AsyncInterrupt so it can be handled in the event loop. If you are attaching and get an async interrupt, abort the attach attempt. Also remember to destroy the process if get interrupted while attaching. Getting this to work also required handing the eBroadcastBitInterrupt in a few more places in Process WaitForEvent & friends. <rdar://problem/10792425> llvm-svn: 160903
2012-07-28 07:57:19 +08:00
eBroadcastBitStateChanged | eBroadcastBitInterrupt,
Fixed an issue in "SBError SBProcess::Destroy ()" where it wasn't properly checking the validity of the shared pointer prior to using it. Fixed the GDB remote plug-in to once again watch for a reply from the "k" packet, and fixed the logic to make sure the thread requesting the kill and the async thread play nice (and very quickly) by synchronizing the packet sending and reply. I also tweaked some of the shut down packet ("k" kill, "D" detach, and the halt packet) to make sure they do the right thing. Fixed "StateType Process::WaitForProcessStopPrivate (...)" to correctly pass the timeout along to WaitForStateChangedEventsPrivate() and made the function behave correctly with respect to timing out. Added separate STDIN, STDOUT, and STDERR support to debugserver. Also added the start of being able to set the working directory for the inferior process. llvm-svn: 124049
2011-01-23 07:43:18 +08:00
event_sp))
Added an lldb_private & equivalent SB API to send an AsyncInterrupt to the event loop. Convert from calling Halt in the lldb Driver.cpp's input reader's sigint handler to sending this AsyncInterrupt so it can be handled in the event loop. If you are attaching and get an async interrupt, abort the attach attempt. Also remember to destroy the process if get interrupted while attaching. Getting this to work also required handing the eBroadcastBitInterrupt in a few more places in Process WaitForEvent & friends. <rdar://problem/10792425> llvm-svn: 160903
2012-07-28 07:57:19 +08:00
if (event_sp && event_sp->GetType() == eBroadcastBitStateChanged)
state = Process::ProcessEventData::GetStateFromEvent(event_sp.get());
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
// 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)
Fixed an issue in "SBError SBProcess::Destroy ()" where it wasn't properly checking the validity of the shared pointer prior to using it. Fixed the GDB remote plug-in to once again watch for a reply from the "k" packet, and fixed the logic to make sure the thread requesting the kill and the async thread play nice (and very quickly) by synchronizing the packet sending and reply. I also tweaked some of the shut down packet ("k" kill, "D" detach, and the halt packet) to make sure they do the right thing. Fixed "StateType Process::WaitForProcessStopPrivate (...)" to correctly pass the timeout along to WaitForStateChangedEventsPrivate() and made the function behave correctly with respect to timing out. Added separate STDIN, STDOUT, and STDERR support to debugserver. Also added the start of being able to set the working directory for the inferior process. llvm-svn: 124049
2011-01-23 07:43:18 +08:00
{
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));
}
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
return state;
}
bool
Process::WaitForEventsPrivate (const TimeValue *timeout, EventSP &event_sp, bool control_only)
{
<rdar://problem/13521159> LLDB is crashing when logging is enabled from lldb-perf-clang. This has to do with the global destructor chain as the process and its threads are being torn down. All logging channels now make one and only one instance that is kept in a global pointer which is never freed. This guarantees that logging can correctly continue as the process tears itself down. llvm-svn: 178191
2013-03-28 07:08:40 +08:00
Log *log(lldb_private::GetLogIfAllCategoriesSet (LIBLLDB_LOG_PROCESS));
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
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;
}
Added the ability for a process to inherit the current host environment. This was done as an settings variable in the process for now. We will eventually move all environment stuff over to the target, but we will leave it with the process for now. The default setting is for a process to inherit the host environment. This can be disabled by setting the "inherit-env" setting to false in the process. llvm-svn: 120862
2010-12-04 08:10:17 +08:00
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
const char *
Process::GetExitDescription ()
{
if (m_public_state.GetValue() == eStateExited && !m_exit_string.empty())
return m_exit_string.c_str();
return NULL;
}
Fixed an issue in "SBError SBProcess::Destroy ()" where it wasn't properly checking the validity of the shared pointer prior to using it. Fixed the GDB remote plug-in to once again watch for a reply from the "k" packet, and fixed the logic to make sure the thread requesting the kill and the async thread play nice (and very quickly) by synchronizing the packet sending and reply. I also tweaked some of the shut down packet ("k" kill, "D" detach, and the halt packet) to make sure they do the right thing. Fixed "StateType Process::WaitForProcessStopPrivate (...)" to correctly pass the timeout along to WaitForStateChangedEventsPrivate() and made the function behave correctly with respect to timing out. Added separate STDIN, STDOUT, and STDERR support to debugserver. Also added the start of being able to set the working directory for the inferior process. llvm-svn: 124049
2011-01-23 07:43:18 +08:00
bool
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
Process::SetExitStatus (int status, const char *cstr)
{
<rdar://problem/13521159> LLDB is crashing when logging is enabled from lldb-perf-clang. This has to do with the global destructor chain as the process and its threads are being torn down. All logging channels now make one and only one instance that is kept in a global pointer which is never freed. This guarantees that logging can correctly continue as the process tears itself down. llvm-svn: 178191
2013-03-28 07:08:40 +08:00
Log *log(lldb_private::GetLogIfAnyCategoriesSet (LIBLLDB_LOG_STATE | LIBLLDB_LOG_PROCESS));
Fixed ProcessGDBRemote to kill the process correctly when it is either running or stopped. Added support for sections to be able to state if they are encrypted or not. llvm-svn: 124171
2011-01-25 10:58:48 +08:00
if (log)
log->Printf("Process::SetExitStatus (status=%i (0x%8.8x), description=%s%s%s)",
status, status,
cstr ? "\"" : "",
cstr ? cstr : "NULL",
cstr ? "\"" : "");
Fixed an issue in "SBError SBProcess::Destroy ()" where it wasn't properly checking the validity of the shared pointer prior to using it. Fixed the GDB remote plug-in to once again watch for a reply from the "k" packet, and fixed the logic to make sure the thread requesting the kill and the async thread play nice (and very quickly) by synchronizing the packet sending and reply. I also tweaked some of the shut down packet ("k" kill, "D" detach, and the halt packet) to make sure they do the right thing. Fixed "StateType Process::WaitForProcessStopPrivate (...)" to correctly pass the timeout along to WaitForStateChangedEventsPrivate() and made the function behave correctly with respect to timing out. Added separate STDIN, STDOUT, and STDERR support to debugserver. Also added the start of being able to set the working directory for the inferior process. llvm-svn: 124049
2011-01-23 07:43:18 +08:00
// We were already in the exited state
if (m_private_state.GetValue() == eStateExited)
Fixed ProcessGDBRemote to kill the process correctly when it is either running or stopped. Added support for sections to be able to state if they are encrypted or not. llvm-svn: 124171
2011-01-25 10:58:48 +08:00
{
Fixed a crasher when there is no log in Process::SetExitStatus (...). llvm-svn: 124338
2011-01-27 07:47:29 +08:00
if (log)
log->Printf("Process::SetExitStatus () ignoring exit status because state was already set to eStateExited");
Fixed an issue in "SBError SBProcess::Destroy ()" where it wasn't properly checking the validity of the shared pointer prior to using it. Fixed the GDB remote plug-in to once again watch for a reply from the "k" packet, and fixed the logic to make sure the thread requesting the kill and the async thread play nice (and very quickly) by synchronizing the packet sending and reply. I also tweaked some of the shut down packet ("k" kill, "D" detach, and the halt packet) to make sure they do the right thing. Fixed "StateType Process::WaitForProcessStopPrivate (...)" to correctly pass the timeout along to WaitForStateChangedEventsPrivate() and made the function behave correctly with respect to timing out. Added separate STDIN, STDOUT, and STDERR support to debugserver. Also added the start of being able to set the working directory for the inferior process. llvm-svn: 124049
2011-01-23 07:43:18 +08:00
return false;
Fixed ProcessGDBRemote to kill the process correctly when it is either running or stopped. Added support for sections to be able to state if they are encrypted or not. llvm-svn: 124171
2011-01-25 10:58:48 +08:00
}
Fixed an issue in "SBError SBProcess::Destroy ()" where it wasn't properly checking the validity of the shared pointer prior to using it. Fixed the GDB remote plug-in to once again watch for a reply from the "k" packet, and fixed the logic to make sure the thread requesting the kill and the async thread play nice (and very quickly) by synchronizing the packet sending and reply. I also tweaked some of the shut down packet ("k" kill, "D" detach, and the halt packet) to make sure they do the right thing. Fixed "StateType Process::WaitForProcessStopPrivate (...)" to correctly pass the timeout along to WaitForStateChangedEventsPrivate() and made the function behave correctly with respect to timing out. Added separate STDIN, STDOUT, and STDERR support to debugserver. Also added the start of being able to set the working directory for the inferior process. llvm-svn: 124049
2011-01-23 07:43:18 +08:00
m_exit_status = status;
if (cstr)
m_exit_string = cstr;
else
m_exit_string.clear();
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
Fixed an issue in "SBError SBProcess::Destroy ()" where it wasn't properly checking the validity of the shared pointer prior to using it. Fixed the GDB remote plug-in to once again watch for a reply from the "k" packet, and fixed the logic to make sure the thread requesting the kill and the async thread play nice (and very quickly) by synchronizing the packet sending and reply. I also tweaked some of the shut down packet ("k" kill, "D" detach, and the halt packet) to make sure they do the right thing. Fixed "StateType Process::WaitForProcessStopPrivate (...)" to correctly pass the timeout along to WaitForStateChangedEventsPrivate() and made the function behave correctly with respect to timing out. Added separate STDIN, STDOUT, and STDERR support to debugserver. Also added the start of being able to set the working directory for the inferior process. llvm-svn: 124049
2011-01-23 07:43:18 +08:00
DidExit ();
Added the ability to dump sections to a certain depth (for when sections have children sections). Modified SectionLoadList to do it's own multi-threaded protected on its map. The ThreadSafeSTLMap class was difficult to deal with and wasn't providing much utility, it was only getting in the way. Make sure when the communication read thread is about to exit, it clears the thread in the main class. Fixed the ModuleList to correctly ignore architectures and UUIDs if they aren't valid when searching for a matching module. If we specified a file with no arch, and then modified the file and loaded it again, it would not match on subsequent searches if the arch was invalid since it would compare an invalid architecture to the one that was found or selected within the shared library or executable. This was causing stale modules to stay around in the global module list when they should have been removed. Removed deprecated functions from the DynamicLoaderMacOSXDYLD class. Modified "ProcessGDBRemote::IsAlive" to check if we are connected to a gdb server and also make sure our process hasn't exited. llvm-svn: 121236
2010-12-08 13:08:21 +08:00
Fixed an issue in "SBError SBProcess::Destroy ()" where it wasn't properly checking the validity of the shared pointer prior to using it. Fixed the GDB remote plug-in to once again watch for a reply from the "k" packet, and fixed the logic to make sure the thread requesting the kill and the async thread play nice (and very quickly) by synchronizing the packet sending and reply. I also tweaked some of the shut down packet ("k" kill, "D" detach, and the halt packet) to make sure they do the right thing. Fixed "StateType Process::WaitForProcessStopPrivate (...)" to correctly pass the timeout along to WaitForStateChangedEventsPrivate() and made the function behave correctly with respect to timing out. Added separate STDIN, STDOUT, and STDERR support to debugserver. Also added the start of being able to set the working directory for the inferior process. llvm-svn: 124049
2011-01-23 07:43:18 +08:00
SetPrivateState (eStateExited);
return true;
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
// 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
Made the darwin host layer properly reap any child processes that it spawns. After recent changes we weren't reaping child processes resulting in many zombie processes. This was fixed by adding more settings to the ProcessLaunchOptions class that allow clients to specify a callback function and baton to be notified when their process dies. If one is not supplied a default callback will be used that "does the right thing". Cleaned up a race condition in the ProcessGDBRemote class that would attempt to monitor when debugserver died. Added an extra boolean to the process monitor callbacks that indicate if a process exited or not. If your process exited with a zero exit status and no signal, both items could be zero. Modified the process monitor functions to not require a callback function in order to reap the child process. llvm-svn: 144780
2011-11-16 13:37:56 +08:00
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
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
)
{
<rdar://problem/13521159> LLDB is crashing when logging is enabled from lldb-perf-clang. This has to do with the global destructor chain as the process and its threads are being torn down. All logging channels now make one and only one instance that is kept in a global pointer which is never freed. This guarantees that logging can correctly continue as the process tears itself down. llvm-svn: 178191
2013-03-28 07:08:40 +08:00
Log *log(lldb_private::GetLogIfAnyCategoriesSet (LIBLLDB_LOG_PROCESS));
Made the darwin host layer properly reap any child processes that it spawns. After recent changes we weren't reaping child processes resulting in many zombie processes. This was fixed by adding more settings to the ProcessLaunchOptions class that allow clients to specify a callback function and baton to be notified when their process dies. If one is not supplied a default callback will be used that "does the right thing". Cleaned up a race condition in the ProcessGDBRemote class that would attempt to monitor when debugserver died. Added an extra boolean to the process monitor callbacks that indicate if a process exited or not. If your process exited with a zero exit status and no signal, both items could be zero. Modified the process monitor functions to not require a callback function in order to reap the child process. llvm-svn: 144780
2011-11-16 13:37:56 +08:00
if (log)
Resolve printf formatting warnings on Linux: - use macros from inttypes.h for format strings instead of OS-specific types Patch from Matt Kopec! llvm-svn: 168945
2012-11-30 05:49:15 +08:00
log->Printf ("Process::SetProcessExitStatus (baton=%p, pid=%" PRIu64 ", exited=%i, signal=%i, exit_status=%i)\n",
Made the darwin host layer properly reap any child processes that it spawns. After recent changes we weren't reaping child processes resulting in many zombie processes. This was fixed by adding more settings to the ProcessLaunchOptions class that allow clients to specify a callback function and baton to be notified when their process dies. If one is not supplied a default callback will be used that "does the right thing". Cleaned up a race condition in the ProcessGDBRemote class that would attempt to monitor when debugserver died. Added an extra boolean to the process monitor callbacks that indicate if a process exited or not. If your process exited with a zero exit status and no signal, both items could be zero. Modified the process monitor functions to not require a callback function in order to reap the child process. llvm-svn: 144780
2011-11-16 13:37:56 +08:00
callback_baton,
pid,
exited,
signo,
exit_status);
if (exited)
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
{
Very large changes that were needed in order to allow multiple connections to the debugger from GUI windows. Previously there was one global debugger instance that could be accessed that had its own command interpreter and current state (current target/process/thread/frame). When a GUI debugger was attached, if it opened more than one window that each had a console window, there were issues where the last one to setup the global debugger object won and got control of the debugger. To avoid this we now create instances of the lldb_private::Debugger that each has its own state: - target list for targets the debugger instance owns - current process/thread/frame - its own command interpreter - its own input, output and error file handles to avoid conflicts - its own input reader stack So now clients should call: SBDebugger::Initialize(); // (static function) SBDebugger debugger (SBDebugger::Create()); // Use which ever file handles you wish debugger.SetErrorFileHandle (stderr, false); debugger.SetOutputFileHandle (stdout, false); debugger.SetInputFileHandle (stdin, true); // main loop SBDebugger::Terminate(); // (static function) SBDebugger::Initialize() and SBDebugger::Terminate() are ref counted to ensure nothing gets destroyed too early when multiple clients might be attached. Cleaned up the command interpreter and the CommandObject and all subclasses to take more appropriate arguments. llvm-svn: 106615
2010-06-23 09:19:29 +08:00
TargetSP target_sp(Debugger::FindTargetWithProcessID (pid));
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
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;
}
Added a new plug-in type: lldb_private::OperatingSystem. The operating system plug-ins are add on plug-ins for the lldb_private::Process class that can add thread contexts that are read from memory. It is common in kernels to have a lot of threads that are not currently executing on any cores (JTAG debugging also follows this sort of thing) and are context switched out whose state is stored in memory data structures. Clients can now subclass the OperatingSystem plug-ins and then make sure their Create functions correcltly only enable themselves when the right binary/target triple are being debugged. The operating system plug-ins get a chance to attach themselves to processes just after launching or attaching and are given a lldb_private::Process object pointer which can be inspected to see if the main executable, target triple, or any shared libraries match a case where the OS plug-in should be used. Currently the OS plug-ins can create new threads, define the register contexts for these threads (which can all be different if desired), and populate and manage the thread info (stop reason, registers in the register context) as the debug session goes on. llvm-svn: 138228
2011-08-22 10:49:39 +08:00
void
Process::UpdateThreadListIfNeeded ()
{
const uint32_t stop_id = GetStopID();
if (m_thread_list.GetSize(false) == 0 || stop_id != m_thread_list.GetStopID())
{
Fixed an issue with the pthread_setspecific() where we weren't NULL-ing out the thread specific data and were destroying the thread specfic data more than once. Also added the ability to ask a lldb::StateType if it is stopped with an additional paramter of "must_exist" which means that the state must be a stopped state for a process that still exists. This means that eStateExited and eStateUnloaded will no longer return true if "must_exist" is set to true. llvm-svn: 144875
2011-11-17 09:23:07 +08:00
const StateType state = GetPrivateState();
if (StateIsStoppedState (state, true))
{
Mutex::Locker locker (m_thread_list.GetMutex ());
Fixed the issue that was causing our monitor process threads to crash, it turned out to be unitialized data in the ProcessLaunchInfo default constructor. Turning on MallocScribble in the environment helped track this down. When we launch and attach using the host layer, we now inform the process that it shouldn't detach when by calling an accessor. llvm-svn: 144882
2011-11-17 12:46:02 +08:00
// 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
Fixed an issue with the pthread_setspecific() where we weren't NULL-ing out the thread specific data and were destroying the thread specfic data more than once. Also added the ability to ask a lldb::StateType if it is stopped with an additional paramter of "must_exist" which means that the state must be a stopped state for a process that still exists. This means that eStateExited and eStateUnloaded will no longer return true if "must_exist" is set to true. llvm-svn: 144875
2011-11-17 09:23:07 +08:00
ThreadList new_thread_list(this);
// Always update the thread list with the protocol specific
Trying to solve our disappearing thread issues by making thread list updates safer. The current ProcessGDBRemote function that updates the threads could end up with an empty list if any other thread had the sequence mutex. We now don't clear the thread list when we can't access it, and we also have changed how lldb_private::Process handles the return code from the: virtual bool Process::UpdateThreadList (lldb_private::ThreadList &old_thread_list, lldb_private::ThreadList &new_thread_list) = 0; A bool is now returned to indicate if the list was actually updated or not and the lldb_private::Process class will only update the stop ID of the validity of the thread list if "true" is returned. The ProcessGDBRemote also got an extra assertion that will hopefully assert when running debug builds so we can find the source of this issue. llvm-svn: 154365
2012-04-10 08:18:59 +08:00
// thread list, but only update if "true" is returned
if (UpdateThreadList (m_thread_list, new_thread_list))
{
Move m_destroy_in_process to Process (from ProcessKDP) since it is generally useful, and use it to keep from doing the OS Plugin UpdateThreadList while destroying, since if that does anything that requires the API lock it may deadlock against whoever is running the Process::Destroy. <rdar://problem/13308627> llvm-svn: 176375
2013-03-02 04:04:25 +08:00
// 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)
os->UpdateThreadList (m_thread_list, new_thread_list);
m_thread_list.Update (new_thread_list);
m_thread_list.SetStopID (stop_id);
}
Trying to solve our disappearing thread issues by making thread list updates safer. The current ProcessGDBRemote function that updates the threads could end up with an empty list if any other thread had the sequence mutex. We now don't clear the thread list when we can't access it, and we also have changed how lldb_private::Process handles the return code from the: virtual bool Process::UpdateThreadList (lldb_private::ThreadList &old_thread_list, lldb_private::ThreadList &new_thread_list) = 0; A bool is now returned to indicate if the list was actually updated or not and the lldb_private::Process class will only update the stop ID of the validity of the thread list if "true" is returned. The ProcessGDBRemote also got an extra assertion that will hopefully assert when running debug builds so we can find the source of this issue. llvm-svn: 154365
2012-04-10 08:18:59 +08:00
}
Fixed an issue with the pthread_setspecific() where we weren't NULL-ing out the thread specific data and were destroying the thread specfic data more than once. Also added the ability to ask a lldb::StateType if it is stopped with an additional paramter of "must_exist" which means that the state must be a stopped state for a process that still exists. This means that eStateExited and eStateUnloaded will no longer return true if "must_exist" is set to true. llvm-svn: 144875
2011-11-17 09:23:07 +08:00
}
Added a new plug-in type: lldb_private::OperatingSystem. The operating system plug-ins are add on plug-ins for the lldb_private::Process class that can add thread contexts that are read from memory. It is common in kernels to have a lot of threads that are not currently executing on any cores (JTAG debugging also follows this sort of thing) and are context switched out whose state is stored in memory data structures. Clients can now subclass the OperatingSystem plug-ins and then make sure their Create functions correcltly only enable themselves when the right binary/target triple are being debugged. The operating system plug-ins get a chance to attach themselves to processes just after launching or attaching and are given a lldb_private::Process object pointer which can be inspected to see if the main executable, target triple, or any shared libraries match a case where the OS plug-in should be used. Currently the OS plug-ins can create new threads, define the register contexts for these threads (which can all be different if desired), and populate and manage the thread info (stop reason, registers in the register context) as the debug session goes on. llvm-svn: 138228
2011-08-22 10:49:39 +08:00
}
}
<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();
}
<rdar://problem/12976225> Checking in the support for doing index ids reservation when given a thread id. llvm-svn: 171904
2013-01-09 06:10:01 +08:00
// This is obsoleted. Staged removal for Xcode.
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
uint32_t
Process::GetNextThreadIndexID ()
{
return ++m_thread_index_id;
}
<rdar://problem/12976225> Checking in the support for doing index ids reservation when given a thread id. llvm-svn: 171904
2013-01-09 06:10:01 +08:00
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;
}
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
StateType
Process::GetState()
{
// If any other threads access this we will need a mutex for it
return m_public_state.GetValue ();
}
void
Process::SetPublicState (StateType new_state)
{
<rdar://problem/13521159> LLDB is crashing when logging is enabled from lldb-perf-clang. This has to do with the global destructor chain as the process and its threads are being torn down. All logging channels now make one and only one instance that is kept in a global pointer which is never freed. This guarantees that logging can correctly continue as the process tears itself down. llvm-svn: 178191
2013-03-28 07:08:40 +08:00
Log *log(lldb_private::GetLogIfAnyCategoriesSet (LIBLLDB_LOG_STATE | LIBLLDB_LOG_PROCESS));
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
if (log)
log->Printf("Process::SetPublicState (%s)", StateAsCString(new_state));
Added a new Host class: ReadWriteLock This abstracts read/write locks on the current host system. It is currently backed by pthread_rwlock_t objects so it should work on all unix systems. We also need a way to control multi-threaded access to the process through the public API when it is running. For example it isn't a good idea to try and get stack frames while the process is running. To implement this, the lldb_private::Process class now contains a ReadWriteLock member variable named m_run_lock which is used to control the public process state. The public process state represents the state of the process as the client knows it. The private is used to control the actual current process state. So the public state of the process can be stopped, yet the private state can be running when evaluating an expression for example. Adding the read/write lock where readers are clients that want the process to stay stopped, and writers are clients that run the process, allows us to accurately control multi-threaded access to the process. Switched the SBThread and SBFrame over to us shared pointers to the ExecutionContextRef class instead of making their own class to track this. This fixed an issue with assigning on SBFrame to another and will also centralize the code that tracks weak references to execution context objects into one location. llvm-svn: 154099
2012-04-06 00:12:35 +08:00
const StateType old_state = m_public_state.GetValue();
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
m_public_state.SetValue (new_state);
Switch to setting the write side of the run lock when we call Resume. Then make a PrivateResume that doesn't switch the run-lock state, and use that where we are resuming without changing the public resume state. llvm-svn: 155092
2012-04-19 09:40:33 +08:00
// 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.
Added a new Host class: ReadWriteLock This abstracts read/write locks on the current host system. It is currently backed by pthread_rwlock_t objects so it should work on all unix systems. We also need a way to control multi-threaded access to the process through the public API when it is running. For example it isn't a good idea to try and get stack frames while the process is running. To implement this, the lldb_private::Process class now contains a ReadWriteLock member variable named m_run_lock which is used to control the public process state. The public process state represents the state of the process as the client knows it. The private is used to control the actual current process state. So the public state of the process can be stopped, yet the private state can be running when evaluating an expression for example. Adding the read/write lock where readers are clients that want the process to stay stopped, and writers are clients that run the process, allows us to accurately control multi-threaded access to the process. Switched the SBThread and SBFrame over to us shared pointers to the ExecutionContextRef class instead of making their own class to track this. This fixed an issue with assigning on SBFrame to another and will also centralize the code that tracks weak references to execution context objects into one location. llvm-svn: 154099
2012-04-06 00:12:35 +08:00
if (!IsHijackedForEvent(eBroadcastBitStateChanged))
{
Fixed a problem where detaching from a process left a read-write lock dangling, causing crashes in debug builds. llvm-svn: 157875
2012-06-02 09:16:20 +08:00
if (new_state == eStateDetached)
Added a new Host class: ReadWriteLock This abstracts read/write locks on the current host system. It is currently backed by pthread_rwlock_t objects so it should work on all unix systems. We also need a way to control multi-threaded access to the process through the public API when it is running. For example it isn't a good idea to try and get stack frames while the process is running. To implement this, the lldb_private::Process class now contains a ReadWriteLock member variable named m_run_lock which is used to control the public process state. The public process state represents the state of the process as the client knows it. The private is used to control the actual current process state. So the public state of the process can be stopped, yet the private state can be running when evaluating an expression for example. Adding the read/write lock where readers are clients that want the process to stay stopped, and writers are clients that run the process, allows us to accurately control multi-threaded access to the process. Switched the SBThread and SBFrame over to us shared pointers to the ExecutionContextRef class instead of making their own class to track this. This fixed an issue with assigning on SBFrame to another and will also centralize the code that tracks weak references to execution context objects into one location. llvm-svn: 154099
2012-04-06 00:12:35 +08:00
{
Fixed a problem where detaching from a process left a read-write lock dangling, causing crashes in debug builds. llvm-svn: 157875
2012-06-02 09:16:20 +08:00
if (log)
log->Printf("Process::SetPublicState (%s) -- unlocking run lock for detach", StateAsCString(new_state));
m_run_lock.WriteUnlock();
}
else
{
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)
Added a new Host class: ReadWriteLock This abstracts read/write locks on the current host system. It is currently backed by pthread_rwlock_t objects so it should work on all unix systems. We also need a way to control multi-threaded access to the process through the public API when it is running. For example it isn't a good idea to try and get stack frames while the process is running. To implement this, the lldb_private::Process class now contains a ReadWriteLock member variable named m_run_lock which is used to control the public process state. The public process state represents the state of the process as the client knows it. The private is used to control the actual current process state. So the public state of the process can be stopped, yet the private state can be running when evaluating an expression for example. Adding the read/write lock where readers are clients that want the process to stay stopped, and writers are clients that run the process, allows us to accurately control multi-threaded access to the process. Switched the SBThread and SBFrame over to us shared pointers to the ExecutionContextRef class instead of making their own class to track this. This fixed an issue with assigning on SBFrame to another and will also centralize the code that tracks weak references to execution context objects into one location. llvm-svn: 154099
2012-04-06 00:12:35 +08:00
{
Fixed a problem where detaching from a process left a read-write lock dangling, causing crashes in debug builds. llvm-svn: 157875
2012-06-02 09:16:20 +08:00
if (new_state_is_stopped)
{
if (log)
log->Printf("Process::SetPublicState (%s) -- unlocking run lock", StateAsCString(new_state));
m_run_lock.WriteUnlock();
}
Added a new Host class: ReadWriteLock This abstracts read/write locks on the current host system. It is currently backed by pthread_rwlock_t objects so it should work on all unix systems. We also need a way to control multi-threaded access to the process through the public API when it is running. For example it isn't a good idea to try and get stack frames while the process is running. To implement this, the lldb_private::Process class now contains a ReadWriteLock member variable named m_run_lock which is used to control the public process state. The public process state represents the state of the process as the client knows it. The private is used to control the actual current process state. So the public state of the process can be stopped, yet the private state can be running when evaluating an expression for example. Adding the read/write lock where readers are clients that want the process to stay stopped, and writers are clients that run the process, allows us to accurately control multi-threaded access to the process. Switched the SBThread and SBFrame over to us shared pointers to the ExecutionContextRef class instead of making their own class to track this. This fixed an issue with assigning on SBFrame to another and will also centralize the code that tracks weak references to execution context objects into one location. llvm-svn: 154099
2012-04-06 00:12:35 +08:00
}
}
}
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
Switch to setting the write side of the run lock when we call Resume. Then make a PrivateResume that doesn't switch the run-lock state, and use that where we are resuming without changing the public resume state. llvm-svn: 155092
2012-04-19 09:40:33 +08:00
Error
Process::Resume ()
{
<rdar://problem/13521159> LLDB is crashing when logging is enabled from lldb-perf-clang. This has to do with the global destructor chain as the process and its threads are being torn down. All logging channels now make one and only one instance that is kept in a global pointer which is never freed. This guarantees that logging can correctly continue as the process tears itself down. llvm-svn: 178191
2013-03-28 07:08:40 +08:00
Log *log(lldb_private::GetLogIfAnyCategoriesSet (LIBLLDB_LOG_STATE | LIBLLDB_LOG_PROCESS));
Switch to setting the write side of the run lock when we call Resume. Then make a PrivateResume that doesn't switch the run-lock state, and use that where we are resuming without changing the public resume state. llvm-svn: 155092
2012-04-19 09:40:33 +08:00
if (log)
log->Printf("Process::Resume -- locking run lock");
if (!m_run_lock.WriteTryLock())
{
Error error("Resume request failed - process still running.");
if (log)
log->Printf ("Process::Resume: -- WriteTryLock failed, not resuming.");
return error;
}
return PrivateResume();
}
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
StateType
Process::GetPrivateState ()
{
return m_private_state.GetValue();
}
void
Process::SetPrivateState (StateType new_state)
{
<rdar://problem/13521159> LLDB is crashing when logging is enabled from lldb-perf-clang. This has to do with the global destructor chain as the process and its threads are being torn down. All logging channels now make one and only one instance that is kept in a global pointer which is never freed. This guarantees that logging can correctly continue as the process tears itself down. llvm-svn: 178191
2013-03-28 07:08:40 +08:00
Log *log(lldb_private::GetLogIfAnyCategoriesSet (LIBLLDB_LOG_STATE | LIBLLDB_LOG_PROCESS));
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
bool state_changed = false;
if (log)
log->Printf("Process::SetPrivateState (%s)", StateAsCString(new_state));
Mutex::Locker locker(m_private_state.GetMutex());
const StateType old_state = m_private_state.GetValueNoLock ();
state_changed = old_state != new_state;
Added a new Host class: ReadWriteLock This abstracts read/write locks on the current host system. It is currently backed by pthread_rwlock_t objects so it should work on all unix systems. We also need a way to control multi-threaded access to the process through the public API when it is running. For example it isn't a good idea to try and get stack frames while the process is running. To implement this, the lldb_private::Process class now contains a ReadWriteLock member variable named m_run_lock which is used to control the public process state. The public process state represents the state of the process as the client knows it. The private is used to control the actual current process state. So the public state of the process can be stopped, yet the private state can be running when evaluating an expression for example. Adding the read/write lock where readers are clients that want the process to stay stopped, and writers are clients that run the process, allows us to accurately control multi-threaded access to the process. Switched the SBThread and SBFrame over to us shared pointers to the ExecutionContextRef class instead of making their own class to track this. This fixed an issue with assigning on SBFrame to another and will also centralize the code that tracks weak references to execution context objects into one location. llvm-svn: 154099
2012-04-06 00:12:35 +08:00
// This code is left commented out in case we ever need to control
// the private process state with another run lock. Right now it doesn't
// seem like we need to do this, but if we ever do, we can uncomment and
// use this code.
// 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)
// m_private_run_lock.WriteUnlock();
// else
// m_private_run_lock.WriteLock();
// }
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
if (state_changed)
{
m_private_state.SetValueNoLock (new_state);
Fixed an issue with the pthread_setspecific() where we weren't NULL-ing out the thread specific data and were destroying the thread specfic data more than once. Also added the ability to ask a lldb::StateType if it is stopped with an additional paramter of "must_exist" which means that the state must be a stopped state for a process that still exists. This means that eStateExited and eStateUnloaded will no longer return true if "must_exist" is set to true. llvm-svn: 144875
2011-11-17 09:23:07 +08:00
if (StateIsStoppedState(new_state, false))
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
{
Move the handling of breakpoint conditions from the Private event loop to the StopInfoBreakpoint::DoActions, which happens as the event is removed. Also use the return value of asynchronous breakpoint callbacks, they get checked before, and override the breakpoint conditions. Added ProcessModInfo class, to unify "stop_id generation" and "memory modification generation", and use where needed. llvm-svn: 137102
2011-08-09 10:12:22 +08:00
m_mod_id.BumpStopID();
Added memory caching to lldb_private::Process. All lldb_private::Process subclasses will automatically be able to take advantage of caching. The cache line size is set to 512 by default. This greatly speeds up stack backtraces on MacOSX when using the ProcessGDBRemote process plug-in since only about 6300 packets per second can be sent. Initial speedups show: Prior to caching: 10,000 stack frames took 5.2 seconds After caching: 10,000 stack frames in 240 ms! About a 20x speedup! llvm-svn: 122996
2011-01-07 14:08:19 +08:00
m_memory_cache.Clear();
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
if (log)
Move the handling of breakpoint conditions from the Private event loop to the StopInfoBreakpoint::DoActions, which happens as the event is removed. Also use the return value of asynchronous breakpoint callbacks, they get checked before, and override the breakpoint conditions. Added ProcessModInfo class, to unify "stop_id generation" and "memory modification generation", and use where needed. llvm-svn: 137102
2011-08-09 10:12:22 +08:00
log->Printf("Process::SetPrivateState (%s) stop_id = %u", StateAsCString(new_state), m_mod_id.GetStopID());
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
// Use our target to get a shared pointer to ourselves...
<rdar://problem/12500785> I tracked down a leak that could happen when detaching from a process where the lldb_private::Process objects would stay around forever. This was caused by a eStateDetached event that was queued up on the lldb_private::Process private state thread listener. Since process events contain shared pointers to the process, this is dangerous if they don't get consume or cleared as having the lldb_private::Process class contain a collection of things that have a shared pointer to yourself is obviously bad. To fix this I modified the Process::Finalize() function to clear this list. The actual thing that was holding onto the ModuleSP and thus the static archive, was a stack frame. Since the process wasn't going away, it still had thread objects and they still had frames. I modified the Thread::Destroy() to clear the stack frames to ensure this further doesn't happen. llvm-svn: 166964
2012-10-30 04:52:08 +08:00
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));
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
else
{
if (log)
Update declarations for all functions/methods that accept printf-style stdarg formats to use __attribute__ format so the compiler can flag incorrect uses. Fix all incorrect uses. Most of these are innocuous, a few were resulting in crashes. llvm-svn: 140185
2011-09-21 05:44:10 +08:00
log->Printf("Process::SetPrivateState (%s) state didn't change. Ignoring...", StateAsCString(new_state));
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
}
Do a better job of detecting when a breakpoint command has set the target running again (except you have to ignore cases where the breakpoint runs expressions, those don't count as really "running again"). llvm-svn: 144064
2011-11-08 11:00:11 +08:00
void
Process::SetRunningUserExpression (bool on)
{
m_mod_id.SetRunningUserExpression (on);
}
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
addr_t
Process::GetImageInfoAddress()
{
return LLDB_INVALID_ADDRESS;
}
Added support for loading and unloading shared libraries. This was done by adding support into lldb_private::Process: virtual uint32_t lldb_private::Process::LoadImage (const FileSpec &image_spec, Error &error); virtual Error lldb_private::Process::UnloadImage (uint32_t image_token); There is a default implementation that should work for both linux and MacOSX. This ability has also been exported through the SBProcess API: uint32_t lldb::SBProcess::LoadImage (lldb::SBFileSpec &image_spec, lldb::SBError &error); lldb::SBError lldb::SBProcess::UnloadImage (uint32_t image_token); Modified the DynamicLoader plug-in interface to require it to be able to tell us if it is currently possible to load/unload a shared library: virtual lldb_private::Error DynamicLoader::CanLoadImage () = 0; This way the dynamic loader plug-ins are allows to veto whether we can currently load a shared library since the dynamic loader might know if it is currenlty loading/unloading shared libraries. It might also know about the current host system and know where to check to make sure runtime or malloc locks are currently being held. Modified the expression parser to have ClangUserExpression::Evaluate() be the one that causes the dynamic checkers to be loaded instead of other code that shouldn't have to worry about it. llvm-svn: 118227
2010-11-04 09:54:29 +08:00
//----------------------------------------------------------------------
// 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)
{
Make sure an error is returned when Process::LoadImage() fails. llvm-svn: 154965
2012-04-18 08:05:19 +08:00
char path[PATH_MAX];
image_spec.GetPath(path, sizeof(path));
Added support for loading and unloading shared libraries. This was done by adding support into lldb_private::Process: virtual uint32_t lldb_private::Process::LoadImage (const FileSpec &image_spec, Error &error); virtual Error lldb_private::Process::UnloadImage (uint32_t image_token); There is a default implementation that should work for both linux and MacOSX. This ability has also been exported through the SBProcess API: uint32_t lldb::SBProcess::LoadImage (lldb::SBFileSpec &image_spec, lldb::SBError &error); lldb::SBError lldb::SBProcess::UnloadImage (uint32_t image_token); Modified the DynamicLoader plug-in interface to require it to be able to tell us if it is currently possible to load/unload a shared library: virtual lldb_private::Error DynamicLoader::CanLoadImage () = 0; This way the dynamic loader plug-ins are allows to veto whether we can currently load a shared library since the dynamic loader might know if it is currenlty loading/unloading shared libraries. It might also know about the current host system and know where to check to make sure runtime or malloc locks are currently being held. Modified the expression parser to have ClangUserExpression::Evaluate() be the one that causes the dynamic checkers to be loaded instead of other code that shouldn't have to worry about it. llvm-svn: 118227
2010-11-04 09:54:29 +08:00
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);
Separated the "expr --unwind-on-error" behavior into two parts, actual errors (i.e. crashes) which continue to be controlled by the --unwind-on-error flag, and --ignore-breakpoint which separately controls behavior when a called function hits a breakpoint. For breakpoints, we don't unwind, we either stop, or ignore the breakpoint, which makes more sense. Also make both these behaviors globally settable through "settings set". Also handle the case where a breakpoint command calls code that ends up re-hitting the breakpoint. We were recursing and crashing. Now we just stop without calling the second command. <rdar://problem/12986644> <rdar://problem/9119325> llvm-svn: 172503
2013-01-15 10:47:48 +08:00
const bool unwind_on_error = true;
const bool ignore_breakpoints = true;
Added support for loading and unloading shared libraries. This was done by adding support into lldb_private::Process: virtual uint32_t lldb_private::Process::LoadImage (const FileSpec &image_spec, Error &error); virtual Error lldb_private::Process::UnloadImage (uint32_t image_token); There is a default implementation that should work for both linux and MacOSX. This ability has also been exported through the SBProcess API: uint32_t lldb::SBProcess::LoadImage (lldb::SBFileSpec &image_spec, lldb::SBError &error); lldb::SBError lldb::SBProcess::UnloadImage (uint32_t image_token); Modified the DynamicLoader plug-in interface to require it to be able to tell us if it is currently possible to load/unload a shared library: virtual lldb_private::Error DynamicLoader::CanLoadImage () = 0; This way the dynamic loader plug-ins are allows to veto whether we can currently load a shared library since the dynamic loader might know if it is currenlty loading/unloading shared libraries. It might also know about the current host system and know where to check to make sure runtime or malloc locks are currently being held. Modified the expression parser to have ClangUserExpression::Evaluate() be the one that causes the dynamic checkers to be loaded instead of other code that shouldn't have to worry about it. llvm-svn: 118227
2010-11-04 09:54:29 +08:00
StreamString expr;
expr.Printf("dlopen (\"%s\", 2)", path);
const char *prefix = "extern \"C\" void* dlopen (const char *path, int mode);\n";
Moved the code in ClangUserExpression that set up & ran the thread plan with timeouts, and restarting with all threads into a utility function in Process. This required a bunch of renaming. Added a ThreadPlanCallUserExpression that differs from ThreadPlanCallFunction in that it holds onto a shared pointer to its ClangUserExpression so that can't go away before the thread plan is done using it. Fixed the stop message when you hit a breakpoint while running a user expression so it is more obvious what has happened. llvm-svn: 120386
2010-11-30 10:22:11 +08:00
lldb::ValueObjectSP result_valobj_sp;
Carlo Kok found an issue where default parameters were causing the wrong argument to be passed. I got rid of the default args so we don't run into this. llvm-svn: 167167
2012-11-01 04:49:04 +08:00
ClangUserExpression::Evaluate (exe_ctx,
eExecutionPolicyAlways,
lldb::eLanguageTypeUnknown,
ClangUserExpression::eResultTypeAny,
unwind_on_error,
Separated the "expr --unwind-on-error" behavior into two parts, actual errors (i.e. crashes) which continue to be controlled by the --unwind-on-error flag, and --ignore-breakpoint which separately controls behavior when a called function hits a breakpoint. For breakpoints, we don't unwind, we either stop, or ignore the breakpoint, which makes more sense. Also make both these behaviors globally settable through "settings set". Also handle the case where a breakpoint command calls code that ends up re-hitting the breakpoint. We were recursing and crashing. Now we just stop without calling the second command. <rdar://problem/12986644> <rdar://problem/9119325> llvm-svn: 172503
2013-01-15 10:47:48 +08:00
ignore_breakpoints,
Carlo Kok found an issue where default parameters were causing the wrong argument to be passed. I got rid of the default args so we don't run into this. llvm-svn: 167167
2012-11-01 04:49:04 +08:00
expr.GetData(),
prefix,
result_valobj_sp,
true,
ClangUserExpression::kDefaultTimeout);
Patch from Filipe! One fixes a trailing comma bug (g++ doesn't like them) The other gets the Error from the result of an expression evaluation and uses it as the error for the Process::LoadImage() method. llvm-svn: 139336
2011-09-09 08:01:43 +08:00
error = result_valobj_sp->GetError();
if (error.Success())
Added support for loading and unloading shared libraries. This was done by adding support into lldb_private::Process: virtual uint32_t lldb_private::Process::LoadImage (const FileSpec &image_spec, Error &error); virtual Error lldb_private::Process::UnloadImage (uint32_t image_token); There is a default implementation that should work for both linux and MacOSX. This ability has also been exported through the SBProcess API: uint32_t lldb::SBProcess::LoadImage (lldb::SBFileSpec &image_spec, lldb::SBError &error); lldb::SBError lldb::SBProcess::UnloadImage (uint32_t image_token); Modified the DynamicLoader plug-in interface to require it to be able to tell us if it is currently possible to load/unload a shared library: virtual lldb_private::Error DynamicLoader::CanLoadImage () = 0; This way the dynamic loader plug-ins are allows to veto whether we can currently load a shared library since the dynamic loader might know if it is currenlty loading/unloading shared libraries. It might also know about the current host system and know where to check to make sure runtime or malloc locks are currently being held. Modified the expression parser to have ClangUserExpression::Evaluate() be the one that causes the dynamic checkers to be loaded instead of other code that shouldn't have to worry about it. llvm-svn: 118227
2010-11-04 09:54:29 +08:00
{
Scalar scalar;
Convert ValueObject to explicitly maintain the Execution Context in which they were created, and then use that when they update themselves. That means all the ValueObject evaluate me type functions that used to require a Frame object now do not. I didn't remove the SBValue API's that take this now useless frame, but I added ones that don't require the frame, and marked the SBFrame taking ones as deprecated. llvm-svn: 128593
2011-03-31 08:19:25 +08:00
if (result_valobj_sp->ResolveValue (scalar))
Added support for loading and unloading shared libraries. This was done by adding support into lldb_private::Process: virtual uint32_t lldb_private::Process::LoadImage (const FileSpec &image_spec, Error &error); virtual Error lldb_private::Process::UnloadImage (uint32_t image_token); There is a default implementation that should work for both linux and MacOSX. This ability has also been exported through the SBProcess API: uint32_t lldb::SBProcess::LoadImage (lldb::SBFileSpec &image_spec, lldb::SBError &error); lldb::SBError lldb::SBProcess::UnloadImage (uint32_t image_token); Modified the DynamicLoader plug-in interface to require it to be able to tell us if it is currently possible to load/unload a shared library: virtual lldb_private::Error DynamicLoader::CanLoadImage () = 0; This way the dynamic loader plug-ins are allows to veto whether we can currently load a shared library since the dynamic loader might know if it is currenlty loading/unloading shared libraries. It might also know about the current host system and know where to check to make sure runtime or malloc locks are currently being held. Modified the expression parser to have ClangUserExpression::Evaluate() be the one that causes the dynamic checkers to be loaded instead of other code that shouldn't have to worry about it. llvm-svn: 118227
2010-11-04 09:54:29 +08:00
{
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;
}
}
}
}
}
}
Make sure an error is returned when Process::LoadImage() fails. llvm-svn: 154965
2012-04-18 08:05:19 +08:00
if (!error.AsCString())
error.SetErrorStringWithFormat("unable to load '%s'", path);
Added support for loading and unloading shared libraries. This was done by adding support into lldb_private::Process: virtual uint32_t lldb_private::Process::LoadImage (const FileSpec &image_spec, Error &error); virtual Error lldb_private::Process::UnloadImage (uint32_t image_token); There is a default implementation that should work for both linux and MacOSX. This ability has also been exported through the SBProcess API: uint32_t lldb::SBProcess::LoadImage (lldb::SBFileSpec &image_spec, lldb::SBError &error); lldb::SBError lldb::SBProcess::UnloadImage (uint32_t image_token); Modified the DynamicLoader plug-in interface to require it to be able to tell us if it is currently possible to load/unload a shared library: virtual lldb_private::Error DynamicLoader::CanLoadImage () = 0; This way the dynamic loader plug-ins are allows to veto whether we can currently load a shared library since the dynamic loader might know if it is currenlty loading/unloading shared libraries. It might also know about the current host system and know where to check to make sure runtime or malloc locks are currently being held. Modified the expression parser to have ClangUserExpression::Evaluate() be the one that causes the dynamic checkers to be loaded instead of other code that shouldn't have to worry about it. llvm-svn: 118227
2010-11-04 09:54:29 +08:00
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);
Separated the "expr --unwind-on-error" behavior into two parts, actual errors (i.e. crashes) which continue to be controlled by the --unwind-on-error flag, and --ignore-breakpoint which separately controls behavior when a called function hits a breakpoint. For breakpoints, we don't unwind, we either stop, or ignore the breakpoint, which makes more sense. Also make both these behaviors globally settable through "settings set". Also handle the case where a breakpoint command calls code that ends up re-hitting the breakpoint. We were recursing and crashing. Now we just stop without calling the second command. <rdar://problem/12986644> <rdar://problem/9119325> llvm-svn: 172503
2013-01-15 10:47:48 +08:00
const bool unwind_on_error = true;
const bool ignore_breakpoints = true;
Added support for loading and unloading shared libraries. This was done by adding support into lldb_private::Process: virtual uint32_t lldb_private::Process::LoadImage (const FileSpec &image_spec, Error &error); virtual Error lldb_private::Process::UnloadImage (uint32_t image_token); There is a default implementation that should work for both linux and MacOSX. This ability has also been exported through the SBProcess API: uint32_t lldb::SBProcess::LoadImage (lldb::SBFileSpec &image_spec, lldb::SBError &error); lldb::SBError lldb::SBProcess::UnloadImage (uint32_t image_token); Modified the DynamicLoader plug-in interface to require it to be able to tell us if it is currently possible to load/unload a shared library: virtual lldb_private::Error DynamicLoader::CanLoadImage () = 0; This way the dynamic loader plug-ins are allows to veto whether we can currently load a shared library since the dynamic loader might know if it is currenlty loading/unloading shared libraries. It might also know about the current host system and know where to check to make sure runtime or malloc locks are currently being held. Modified the expression parser to have ClangUserExpression::Evaluate() be the one that causes the dynamic checkers to be loaded instead of other code that shouldn't have to worry about it. llvm-svn: 118227
2010-11-04 09:54:29 +08:00
StreamString expr;
Resolve printf formatting warnings on Linux: - use macros from inttypes.h for format strings instead of OS-specific types Patch from Matt Kopec! llvm-svn: 168945
2012-11-30 05:49:15 +08:00
expr.Printf("dlclose ((void *)0x%" PRIx64 ")", image_addr);
Added support for loading and unloading shared libraries. This was done by adding support into lldb_private::Process: virtual uint32_t lldb_private::Process::LoadImage (const FileSpec &image_spec, Error &error); virtual Error lldb_private::Process::UnloadImage (uint32_t image_token); There is a default implementation that should work for both linux and MacOSX. This ability has also been exported through the SBProcess API: uint32_t lldb::SBProcess::LoadImage (lldb::SBFileSpec &image_spec, lldb::SBError &error); lldb::SBError lldb::SBProcess::UnloadImage (uint32_t image_token); Modified the DynamicLoader plug-in interface to require it to be able to tell us if it is currently possible to load/unload a shared library: virtual lldb_private::Error DynamicLoader::CanLoadImage () = 0; This way the dynamic loader plug-ins are allows to veto whether we can currently load a shared library since the dynamic loader might know if it is currenlty loading/unloading shared libraries. It might also know about the current host system and know where to check to make sure runtime or malloc locks are currently being held. Modified the expression parser to have ClangUserExpression::Evaluate() be the one that causes the dynamic checkers to be loaded instead of other code that shouldn't have to worry about it. llvm-svn: 118227
2010-11-04 09:54:29 +08:00
const char *prefix = "extern \"C\" int dlclose(void* handle);\n";
Moved the code in ClangUserExpression that set up & ran the thread plan with timeouts, and restarting with all threads into a utility function in Process. This required a bunch of renaming. Added a ThreadPlanCallUserExpression that differs from ThreadPlanCallFunction in that it holds onto a shared pointer to its ClangUserExpression so that can't go away before the thread plan is done using it. Fixed the stop message when you hit a breakpoint while running a user expression so it is more obvious what has happened. llvm-svn: 120386
2010-11-30 10:22:11 +08:00
lldb::ValueObjectSP result_valobj_sp;
Carlo Kok found an issue where default parameters were causing the wrong argument to be passed. I got rid of the default args so we don't run into this. llvm-svn: 167167
2012-11-01 04:49:04 +08:00
ClangUserExpression::Evaluate (exe_ctx,
eExecutionPolicyAlways,
lldb::eLanguageTypeUnknown,
ClangUserExpression::eResultTypeAny,
unwind_on_error,
Separated the "expr --unwind-on-error" behavior into two parts, actual errors (i.e. crashes) which continue to be controlled by the --unwind-on-error flag, and --ignore-breakpoint which separately controls behavior when a called function hits a breakpoint. For breakpoints, we don't unwind, we either stop, or ignore the breakpoint, which makes more sense. Also make both these behaviors globally settable through "settings set". Also handle the case where a breakpoint command calls code that ends up re-hitting the breakpoint. We were recursing and crashing. Now we just stop without calling the second command. <rdar://problem/12986644> <rdar://problem/9119325> llvm-svn: 172503
2013-01-15 10:47:48 +08:00
ignore_breakpoints,
Carlo Kok found an issue where default parameters were causing the wrong argument to be passed. I got rid of the default args so we don't run into this. llvm-svn: 167167
2012-11-01 04:49:04 +08:00
expr.GetData(),
prefix,
result_valobj_sp,
true,
ClangUserExpression::kDefaultTimeout);
Added support for loading and unloading shared libraries. This was done by adding support into lldb_private::Process: virtual uint32_t lldb_private::Process::LoadImage (const FileSpec &image_spec, Error &error); virtual Error lldb_private::Process::UnloadImage (uint32_t image_token); There is a default implementation that should work for both linux and MacOSX. This ability has also been exported through the SBProcess API: uint32_t lldb::SBProcess::LoadImage (lldb::SBFileSpec &image_spec, lldb::SBError &error); lldb::SBError lldb::SBProcess::UnloadImage (uint32_t image_token); Modified the DynamicLoader plug-in interface to require it to be able to tell us if it is currently possible to load/unload a shared library: virtual lldb_private::Error DynamicLoader::CanLoadImage () = 0; This way the dynamic loader plug-ins are allows to veto whether we can currently load a shared library since the dynamic loader might know if it is currenlty loading/unloading shared libraries. It might also know about the current host system and know where to check to make sure runtime or malloc locks are currently being held. Modified the expression parser to have ClangUserExpression::Evaluate() be the one that causes the dynamic checkers to be loaded instead of other code that shouldn't have to worry about it. llvm-svn: 118227
2010-11-04 09:54:29 +08:00
if (result_valobj_sp->GetError().Success())
{
Scalar scalar;
Convert ValueObject to explicitly maintain the Execution Context in which they were created, and then use that when they update themselves. That means all the ValueObject evaluate me type functions that used to require a Frame object now do not. I didn't remove the SBValue API's that take this now useless frame, but I added ones that don't require the frame, and marked the SBFrame taking ones as deprecated. llvm-svn: 128593
2011-03-31 08:19:25 +08:00
if (result_valobj_sp->ResolveValue (scalar))
Added support for loading and unloading shared libraries. This was done by adding support into lldb_private::Process: virtual uint32_t lldb_private::Process::LoadImage (const FileSpec &image_spec, Error &error); virtual Error lldb_private::Process::UnloadImage (uint32_t image_token); There is a default implementation that should work for both linux and MacOSX. This ability has also been exported through the SBProcess API: uint32_t lldb::SBProcess::LoadImage (lldb::SBFileSpec &image_spec, lldb::SBError &error); lldb::SBError lldb::SBProcess::UnloadImage (uint32_t image_token); Modified the DynamicLoader plug-in interface to require it to be able to tell us if it is currently possible to load/unload a shared library: virtual lldb_private::Error DynamicLoader::CanLoadImage () = 0; This way the dynamic loader plug-ins are allows to veto whether we can currently load a shared library since the dynamic loader might know if it is currenlty loading/unloading shared libraries. It might also know about the current host system and know where to check to make sure runtime or malloc locks are currently being held. Modified the expression parser to have ClangUserExpression::Evaluate() be the one that causes the dynamic checkers to be loaded instead of other code that shouldn't have to worry about it. llvm-svn: 118227
2010-11-04 09:54:29 +08:00
{
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;
}
Moved all code from ArchDefaultUnwindPlan and ArchVolatileRegs into their respective ABI plugins as they were plug-ins that supplied ABI specfic info. Also hookep up the UnwindAssemblyInstEmulation so that it can generate the unwind plans for ARM. Changed the way ABI plug-ins are handed out when you get an instance from the plug-in manager. They used to return pointers that would be mananged individually by each client that requested them, but now they are handed out as shared pointers since there is no state in the ABI objects, they can be shared. llvm-svn: 131193
2011-05-12 02:39:18 +08:00
const lldb::ABISP &
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
Process::GetABI()
{
Moved all code from ArchDefaultUnwindPlan and ArchVolatileRegs into their respective ABI plugins as they were plug-ins that supplied ABI specfic info. Also hookep up the UnwindAssemblyInstEmulation so that it can generate the unwind plans for ARM. Changed the way ABI plug-ins are handed out when you get an instance from the plug-in manager. They used to return pointers that would be mananged individually by each client that requested them, but now they are handed out as shared pointers since there is no state in the ABI objects, they can be shared. llvm-svn: 131193
2011-05-12 02:39:18 +08:00
if (!m_abi_sp)
m_abi_sp = ABI::FindPlugin(m_target.GetArchitecture());
return m_abi_sp;
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
Committing the skeleton of Language runtime plugin classes. llvm-svn: 114620
2010-09-23 10:01:19 +08:00
LanguageRuntime *
Fix the process of getting the ObjC runtime - if we ask for it too early (in the process of handling the load notification for the first load) then we will set it the runtime to NULL and won't re-search for it. Added a way for the dynamic loader to force a re-search, since it knows the world has changed. llvm-svn: 152453
2012-03-10 08:22:19 +08:00
Process::GetLanguageRuntime(lldb::LanguageType language, bool retry_if_null)
Committing the skeleton of Language runtime plugin classes. llvm-svn: 114620
2010-09-23 10:01:19 +08:00
{
LanguageRuntimeCollection::iterator pos;
pos = m_language_runtimes.find (language);
Fix the process of getting the ObjC runtime - if we ask for it too early (in the process of handling the load notification for the first load) then we will set it the runtime to NULL and won't re-search for it. Added a way for the dynamic loader to force a re-search, since it knows the world has changed. llvm-svn: 152453
2012-03-10 08:22:19 +08:00
if (pos == m_language_runtimes.end() || (retry_if_null && !(*pos).second))
Committing the skeleton of Language runtime plugin classes. llvm-svn: 114620
2010-09-23 10:01:19 +08:00
{
Fix the process of getting the ObjC runtime - if we ask for it too early (in the process of handling the load notification for the first load) then we will set it the runtime to NULL and won't re-search for it. Added a way for the dynamic loader to force a re-search, since it knows the world has changed. llvm-svn: 152453
2012-03-10 08:22:19 +08:00
lldb::LanguageRuntimeSP runtime_sp(LanguageRuntime::FindPlugin(this, language));
Committing the skeleton of Language runtime plugin classes. llvm-svn: 114620
2010-09-23 10:01:19 +08:00
Fix the process of getting the ObjC runtime - if we ask for it too early (in the process of handling the load notification for the first load) then we will set it the runtime to NULL and won't re-search for it. Added a way for the dynamic loader to force a re-search, since it knows the world has changed. llvm-svn: 152453
2012-03-10 08:22:19 +08:00
m_language_runtimes[language] = runtime_sp;
return runtime_sp.get();
Committing the skeleton of Language runtime plugin classes. llvm-svn: 114620
2010-09-23 10:01:19 +08:00
}
else
return (*pos).second.get();
}
CPPLanguageRuntime *
Fix the process of getting the ObjC runtime - if we ask for it too early (in the process of handling the load notification for the first load) then we will set it the runtime to NULL and won't re-search for it. Added a way for the dynamic loader to force a re-search, since it knows the world has changed. llvm-svn: 152453
2012-03-10 08:22:19 +08:00
Process::GetCPPLanguageRuntime (bool retry_if_null)
Committing the skeleton of Language runtime plugin classes. llvm-svn: 114620
2010-09-23 10:01:19 +08:00
{
Fix the process of getting the ObjC runtime - if we ask for it too early (in the process of handling the load notification for the first load) then we will set it the runtime to NULL and won't re-search for it. Added a way for the dynamic loader to force a re-search, since it knows the world has changed. llvm-svn: 152453
2012-03-10 08:22:19 +08:00
LanguageRuntime *runtime = GetLanguageRuntime(eLanguageTypeC_plus_plus, retry_if_null);
Committing the skeleton of Language runtime plugin classes. llvm-svn: 114620
2010-09-23 10:01:19 +08:00
if (runtime != NULL && runtime->GetLanguageType() == eLanguageTypeC_plus_plus)
return static_cast<CPPLanguageRuntime *> (runtime);
return NULL;
}
ObjCLanguageRuntime *
Fix the process of getting the ObjC runtime - if we ask for it too early (in the process of handling the load notification for the first load) then we will set it the runtime to NULL and won't re-search for it. Added a way for the dynamic loader to force a re-search, since it knows the world has changed. llvm-svn: 152453
2012-03-10 08:22:19 +08:00
Process::GetObjCLanguageRuntime (bool retry_if_null)
Committing the skeleton of Language runtime plugin classes. llvm-svn: 114620
2010-09-23 10:01:19 +08:00
{
Fix the process of getting the ObjC runtime - if we ask for it too early (in the process of handling the load notification for the first load) then we will set it the runtime to NULL and won't re-search for it. Added a way for the dynamic loader to force a re-search, since it knows the world has changed. llvm-svn: 152453
2012-03-10 08:22:19 +08:00
LanguageRuntime *runtime = GetLanguageRuntime(eLanguageTypeObjC, retry_if_null);
Committing the skeleton of Language runtime plugin classes. llvm-svn: 114620
2010-09-23 10:01:19 +08:00
if (runtime != NULL && runtime->GetLanguageType() == eLanguageTypeObjC)
return static_cast<ObjCLanguageRuntime *> (runtime);
return NULL;
}
<rdar://problem/11355592> Fixing a bug where we would incorrectly try and determine a dynamic type for a variable of a pointer type that is not a valid generic type for dynamic pointers. llvm-svn: 157190
2012-05-22 00:51:35 +08:00
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;
}
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
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.SetEnabledForAll (false);
Work around some problems destroying a process with older debugservers. rdar://problem/11359989 llvm-svn: 159697
2012-07-04 08:35:43 +08:00
size_t num_sites = m_breakpoint_site_list.GetSize();
for (size_t i = 0; i < num_sites; i++)
{
A little cleanup. {Disable/Enable}Breakpoint actually disables/enables BreakpointSites not breakpoints, it is confusing to have it not named appropriately. Also in StopInfoMachException, we aren't testing for software or not software, just whether the thing is a breakpoint we set. So don't use "software"... llvm-svn: 175241
2013-02-15 10:06:30 +08:00
DisableBreakpointSite (m_breakpoint_site_list.GetByIndex(i).get());
Work around some problems destroying a process with older debugservers. rdar://problem/11359989 llvm-svn: 159697
2012-07-04 08:35:43 +08:00
}
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
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())
A little cleanup. {Disable/Enable}Breakpoint actually disables/enables BreakpointSites not breakpoints, it is confusing to have it not named appropriately. Also in StopInfoMachException, we aren't testing for software or not software, just whether the thing is a breakpoint we set. So don't use "software"... llvm-svn: 175241
2013-02-15 10:06:30 +08:00
error = DisableBreakpointSite (bp_site_sp.get());
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
else
{
Resolve printf formatting warnings on Linux: - use macros from inttypes.h for format strings instead of OS-specific types Patch from Matt Kopec! llvm-svn: 168945
2012-11-30 05:49:15 +08:00
error.SetErrorStringWithFormat("invalid breakpoint site ID: %" PRIu64, break_id);
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
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())
A little cleanup. {Disable/Enable}Breakpoint actually disables/enables BreakpointSites not breakpoints, it is confusing to have it not named appropriately. Also in StopInfoMachException, we aren't testing for software or not software, just whether the thing is a breakpoint we set. So don't use "software"... llvm-svn: 175241
2013-02-15 10:06:30 +08:00
error = EnableBreakpointSite (bp_site_sp.get());
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
else
{
Resolve printf formatting warnings on Linux: - use macros from inttypes.h for format strings instead of OS-specific types Patch from Matt Kopec! llvm-svn: 168945
2012-11-30 05:49:15 +08:00
error.SetErrorStringWithFormat("invalid breakpoint site ID: %" PRIu64, break_id);
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
return error;
}
Have Process::CreateBreakpointSite return a break_id_t instead of a user_id_t. Also, update BreakpointLocation::ResolveBreakpointSite to check for invalid breakpoint ID's using the proper magic constant. llvm-svn: 108598
2010-07-17 08:56:13 +08:00
lldb::break_id_t
Switching back to using std::tr1::shared_ptr. We originally switched away due to RTTI worries since llvm and clang don't use RTTI, but I was able to switch back with no issues as far as I can tell. Once the RTTI issue wasn't an issue, we were looking for a way to properly track weak pointers to objects to solve some of the threading issues we have been running into which naturally led us back to std::tr1::weak_ptr. We also wanted the ability to make a shared pointer from just a pointer, which is also easily solved using the std::tr1::enable_shared_from_this class. The main reason for this move back is so we can start properly having weak references to objects. Currently a lldb_private::Thread class has a refrence to its parent lldb_private::Process. This doesn't work well when we now hand out a SBThread object that contains a shared pointer to a lldb_private::Thread as this SBThread can be held onto by external clients and if they end up using one of these objects we can easily crash. So the next task is to start adopting std::tr1::weak_ptr where ever it makes sense which we can do with lldb_private::Debugger, lldb_private::Target, lldb_private::Process, lldb_private::Thread, lldb_private::StackFrame, and many more objects now that they are no longer using intrusive ref counted pointer objects (you can't do std::tr1::weak_ptr functionality with intrusive pointers). llvm-svn: 149207
2012-01-30 04:56:30 +08:00
Process::CreateBreakpointSite (const BreakpointLocationSP &owner, bool use_hardware)
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
{
Moved a lot of simple functions from StoppointLocation.cpp to be inlined in StoppointLocation.h. Added a new lldb_private::Address function: addr_t Address::GetOpcodeLoadAddress (Target *target) const; This will strip any special bits from an address to make sure it is suitable for use in addressing an opcode. Often ARM addresses have an extra bit zero that can be set to indicate ARM vs Thumb addresses (gotten from return address registers, or symbol addresses that may be marked up specially). We need to strip these bits off prior to setting breakpoints, so we can centralized the place to do this inside the Address class. llvm-svn: 131658
2011-05-20 02:17:41 +08:00
const addr_t load_addr = owner->GetAddress().GetOpcodeLoadAddress (&m_target);
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
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
{
<rdar://problem/13069948> Major fixed to allow reading files that are over 4GB. The main problems were that the DataExtractor was using 32 bit offsets as a data cursor, and since we mmap all of our object files we could run into cases where if we had a very large core file that was over 4GB, we were running into the 4GB boundary. So I defined a new "lldb::offset_t" which should be used for all file offsets. After making this change, I enabled warnings for data loss and for enexpected implicit conversions temporarily and found a ton of things that I fixed. Any functions that take an index internally, should use "size_t" for any indexes and also should return "size_t" for any sizes of collections. llvm-svn: 173463
2013-01-26 02:06:21 +08:00
bp_site_sp.reset (new BreakpointSite (&m_breakpoint_site_list, owner, load_addr, use_hardware));
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
if (bp_site_sp)
{
A little cleanup. {Disable/Enable}Breakpoint actually disables/enables BreakpointSites not breakpoints, it is confusing to have it not named appropriately. Also in StopInfoMachException, we aren't testing for software or not software, just whether the thing is a breakpoint we set. So don't use "software"... llvm-svn: 175241
2013-02-15 10:06:30 +08:00
if (EnableBreakpointSite (bp_site_sp.get()).Success())
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
{
owner->SetBreakpointSite (bp_site_sp);
return m_breakpoint_site_list.Add (bp_site_sp);
}
}
}
}
// 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)
{
A little cleanup. {Disable/Enable}Breakpoint actually disables/enables BreakpointSites not breakpoints, it is confusing to have it not named appropriately. Also in StopInfoMachException, we aren't testing for software or not software, just whether the thing is a breakpoint we set. So don't use "software"... llvm-svn: 175241
2013-02-15 10:06:30 +08:00
DisableBreakpointSite (bp_site_sp.get());
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
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;
addr_t intersect_addr;
size_t intersect_size;
size_t opcode_offset;
size_t idx;
Adopt the intrusive pointers in: lldb_private::Breakpoint lldb_private::BreakpointLocations lldb_private::BreakpointSite lldb_private::Debugger lldb_private::StackFrame lldb_private::Thread lldb_private::Target llvm-svn: 139985
2011-09-17 16:33:22 +08:00
BreakpointSiteSP bp_sp;
Remove a few more places where we were iterating linearly over the Breakpoint Site's rather than looking up what we needed by address, which is much faster. llvm-svn: 134090
2011-06-30 03:42:28 +08:00
BreakpointSiteList bp_sites_in_range;
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
Remove a few more places where we were iterating linearly over the Breakpoint Site's rather than looking up what we needed by address, which is much faster. llvm-svn: 134090
2011-06-30 03:42:28 +08:00
if (m_breakpoint_site_list.FindInRange (bp_addr, bp_addr + size, bp_sites_in_range))
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
{
Adopt the intrusive pointers in: lldb_private::Breakpoint lldb_private::BreakpointLocations lldb_private::BreakpointSite lldb_private::Debugger lldb_private::StackFrame lldb_private::Thread lldb_private::Target llvm-svn: 139985
2011-09-17 16:33:22 +08:00
for (idx = 0; (bp_sp = bp_sites_in_range.GetByIndex(idx)); ++idx)
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
{
Adopt the intrusive pointers in: lldb_private::Breakpoint lldb_private::BreakpointLocations lldb_private::BreakpointSite lldb_private::Debugger lldb_private::StackFrame lldb_private::Thread lldb_private::Target llvm-svn: 139985
2011-09-17 16:33:22 +08:00
if (bp_sp->GetType() == BreakpointSite::eSoftware)
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
{
Adopt the intrusive pointers in: lldb_private::Breakpoint lldb_private::BreakpointLocations lldb_private::BreakpointSite lldb_private::Debugger lldb_private::StackFrame lldb_private::Thread lldb_private::Target llvm-svn: 139985
2011-09-17 16:33:22 +08:00
if (bp_sp->IntersectsRange(bp_addr, size, &intersect_addr, &intersect_size, &opcode_offset))
Remove a few more places where we were iterating linearly over the Breakpoint Site's rather than looking up what we needed by address, which is much faster. llvm-svn: 134090
2011-06-30 03:42:28 +08:00
{
assert(bp_addr <= intersect_addr && intersect_addr < bp_addr + size);
assert(bp_addr < intersect_addr + intersect_size && intersect_addr + intersect_size <= bp_addr + size);
Adopt the intrusive pointers in: lldb_private::Breakpoint lldb_private::BreakpointLocations lldb_private::BreakpointSite lldb_private::Debugger lldb_private::StackFrame lldb_private::Thread lldb_private::Target llvm-svn: 139985
2011-09-17 16:33:22 +08:00
assert(opcode_offset + intersect_size <= bp_sp->GetByteSize());
Remove a few more places where we were iterating linearly over the Breakpoint Site's rather than looking up what we needed by address, which is much faster. llvm-svn: 134090
2011-06-30 03:42:28 +08:00
size_t buf_offset = intersect_addr - bp_addr;
Adopt the intrusive pointers in: lldb_private::Breakpoint lldb_private::BreakpointLocations lldb_private::BreakpointSite lldb_private::Debugger lldb_private::StackFrame lldb_private::Thread lldb_private::Target llvm-svn: 139985
2011-09-17 16:33:22 +08:00
::memcpy(buf + buf_offset, bp_sp->GetSavedOpcodeBytes() + opcode_offset, intersect_size);
Remove a few more places where we were iterating linearly over the Breakpoint Site's rather than looking up what we needed by address, which is much faster. llvm-svn: 134090
2011-06-30 03:42:28 +08:00
}
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
}
}
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;
}
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
Error
Process::EnableSoftwareBreakpoint (BreakpointSite *bp_site)
{
Error error;
assert (bp_site != NULL);
<rdar://problem/13521159> LLDB is crashing when logging is enabled from lldb-perf-clang. This has to do with the global destructor chain as the process and its threads are being torn down. All logging channels now make one and only one instance that is kept in a global pointer which is never freed. This guarantees that logging can correctly continue as the process tears itself down. llvm-svn: 178191
2013-03-28 07:08:40 +08:00
Log *log(lldb_private::GetLogIfAnyCategoriesSet (LIBLLDB_LOG_BREAKPOINTS));
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
const addr_t bp_addr = bp_site->GetLoadAddress();
if (log)
Resolve printf formatting warnings on Linux: - use macros from inttypes.h for format strings instead of OS-specific types Patch from Matt Kopec! llvm-svn: 168945
2012-11-30 05:49:15 +08:00
log->Printf ("Process::EnableSoftwareBreakpoint (site_id = %d) addr = 0x%" PRIx64, bp_site->GetID(), (uint64_t)bp_addr);
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
if (bp_site->IsEnabled())
{
if (log)
Resolve printf formatting warnings on Linux: - use macros from inttypes.h for format strings instead of OS-specific types Patch from Matt Kopec! llvm-svn: 168945
2012-11-30 05:49:15 +08:00
log->Printf ("Process::EnableSoftwareBreakpoint (site_id = %d) addr = 0x%" PRIx64 " -- already enabled", bp_site->GetID(), (uint64_t)bp_addr);
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
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)
{
Resolve printf formatting warnings on Linux: - use macros from inttypes.h for format strings instead of OS-specific types Patch from Matt Kopec! llvm-svn: 168945
2012-11-30 05:49:15 +08:00
error.SetErrorStringWithFormat ("Process::GetSoftwareBreakpointTrapOpcode() returned zero, unable to get breakpoint trap for address 0x%" PRIx64, bp_addr);
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
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)
Resolve printf formatting warnings on Linux: - use macros from inttypes.h for format strings instead of OS-specific types Patch from Matt Kopec! llvm-svn: 168945
2012-11-30 05:49:15 +08:00
log->Printf ("Process::EnableSoftwareBreakpoint (site_id = %d) addr = 0x%" PRIx64 " -- SUCCESS",
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
bp_site->GetID(),
(uint64_t)bp_addr);
}
else
Cleaned up many error codes. For any who is filling in error strings into lldb_private::Error objects the rules are: - short strings that don't start with a capitol letter unless the name is a class or anything else that is always capitolized - no trailing newline character - should be one line if possible Implemented a first pass at adding "--gdb-format" support to anything that accepts format with optional size/count. llvm-svn: 142999
2011-10-26 08:56:27 +08:00
error.SetErrorString("failed to verify the breakpoint trap in memory.");
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
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.");
}
Log diagnostic when setting software breakpoints only on failure. Previously we would be posting a "FAILED" message to the log channel even when the operation succeeded. Also, take this opportunity to add braces thus eliminating an "ambiguous else" compiler warning. llvm-svn: 123306
2011-01-12 12:20:03 +08:00
if (log && error.Fail())
Resolve printf formatting warnings on Linux: - use macros from inttypes.h for format strings instead of OS-specific types Patch from Matt Kopec! llvm-svn: 168945
2012-11-30 05:49:15 +08:00
log->Printf ("Process::EnableSoftwareBreakpoint (site_id = %d) addr = 0x%" PRIx64 " -- FAILED: %s",
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
bp_site->GetID(),
(uint64_t)bp_addr,
error.AsCString());
return error;
}
Error
Process::DisableSoftwareBreakpoint (BreakpointSite *bp_site)
{
Error error;
assert (bp_site != NULL);
<rdar://problem/13521159> LLDB is crashing when logging is enabled from lldb-perf-clang. This has to do with the global destructor chain as the process and its threads are being torn down. All logging channels now make one and only one instance that is kept in a global pointer which is never freed. This guarantees that logging can correctly continue as the process tears itself down. llvm-svn: 178191
2013-03-28 07:08:40 +08:00
Log *log(lldb_private::GetLogIfAnyCategoriesSet (LIBLLDB_LOG_BREAKPOINTS));
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
addr_t bp_addr = bp_site->GetLoadAddress();
lldb::user_id_t breakID = bp_site->GetID();
if (log)
A little cleanup. {Disable/Enable}Breakpoint actually disables/enables BreakpointSites not breakpoints, it is confusing to have it not named appropriately. Also in StopInfoMachException, we aren't testing for software or not software, just whether the thing is a breakpoint we set. So don't use "software"... llvm-svn: 175241
2013-02-15 10:06:30 +08:00
log->Printf ("Process::DisableSoftwareBreakpoint (breakID = %" PRIu64 ") addr = 0x%" PRIx64, breakID, (uint64_t)bp_addr);
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
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
Merged Eli Friedman's linux build changes where he added Makefile files that enabled LLVM make style building and made this compile LLDB on Mac OS X. We can now iterate on this to make the build work on both linux and macosx. llvm-svn: 108009
2010-07-10 04:39:50 +08:00
uint8_t curr_break_op[8];
Fix assertion conditions. llvm-svn: 108879
2010-07-21 02:41:11 +08:00
assert (break_op_size <= sizeof(curr_break_op));
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
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)
{
Merged Eli Friedman's linux build changes where he added Makefile files that enabled LLVM make style building and made this compile LLDB on Mac OS X. We can now iterate on this to make the build work on both linux and macosx. llvm-svn: 108009
2010-07-10 04:39:50 +08:00
uint8_t verify_opcode[8];
Fix assertion conditions. llvm-svn: 108879
2010-07-21 02:41:11 +08:00
assert (break_op_size < sizeof(verify_opcode));
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
// 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)
Resolve printf formatting warnings on Linux: - use macros from inttypes.h for format strings instead of OS-specific types Patch from Matt Kopec! llvm-svn: 168945
2012-11-30 05:49:15 +08:00
log->Printf ("Process::DisableSoftwareBreakpoint (site_id = %d) addr = 0x%" PRIx64 " -- SUCCESS", bp_site->GetID(), (uint64_t)bp_addr);
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
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)
Resolve printf formatting warnings on Linux: - use macros from inttypes.h for format strings instead of OS-specific types Patch from Matt Kopec! llvm-svn: 168945
2012-11-30 05:49:15 +08:00
log->Printf ("Process::DisableSoftwareBreakpoint (site_id = %d) addr = 0x%" PRIx64 " -- already disabled", bp_site->GetID(), (uint64_t)bp_addr);
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
return error;
}
if (log)
Resolve printf formatting warnings on Linux: - use macros from inttypes.h for format strings instead of OS-specific types Patch from Matt Kopec! llvm-svn: 168945
2012-11-30 05:49:15 +08:00
log->Printf ("Process::DisableSoftwareBreakpoint (site_id = %d) addr = 0x%" PRIx64 " -- FAILED: %s",
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
bp_site->GetID(),
(uint64_t)bp_addr,
error.AsCString());
return error;
}
Added memory caching to lldb_private::Process. All lldb_private::Process subclasses will automatically be able to take advantage of caching. The cache line size is set to 512 by default. This greatly speeds up stack backtraces on MacOSX when using the ProcessGDBRemote process plug-in since only about 6300 packets per second can be sent. Initial speedups show: Prior to caching: 10,000 stack frames took 5.2 seconds After caching: 10,000 stack frames in 240 ms! About a 20x speedup! llvm-svn: 122996
2011-01-07 14:08:19 +08:00
// 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)
{
Added a setting (target.process.disable-memory-cache) that controls whether memory is cached. This is off by default (i.e., memory is cached) because it greatly improves performance. llvm-svn: 158173
2012-06-08 06:26:42 +08:00
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);
Added memory caching to lldb_private::Process. All lldb_private::Process subclasses will automatically be able to take advantage of caching. The cache line size is set to 512 by default. This greatly speeds up stack backtraces on MacOSX when using the ProcessGDBRemote process plug-in since only about 6300 packets per second can be sent. Initial speedups show: Prior to caching: 10,000 stack frames took 5.2 seconds After caching: 10,000 stack frames in 240 ms! About a 20x speedup! llvm-svn: 122996
2011-01-07 14:08:19 +08:00
}
}
Found a quick way to improve the speed with which we can read object files from memory when they are in the shared cache: always read the symbol table strings from memory and let the process' memory cache do the work. llvm-svn: 157083
2012-05-19 07:20:01 +08:00
size_t
Process::ReadCStringFromMemory (addr_t addr, std::string &out_str, Error &error)
{
Forgot to bump the local string buffer up in size after debugging to make sure long strings would be correctly read when the buffer is too small for the string. llvm-svn: 157087
2012-05-19 08:18:00 +08:00
char buf[256];
Found a quick way to improve the speed with which we can read object files from memory when they are in the shared cache: always read the symbol table strings from memory and let the process' memory cache do the work. llvm-svn: 157083
2012-05-19 07:20:01 +08:00
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();
}
Added memory caching to lldb_private::Process. All lldb_private::Process subclasses will automatically be able to take advantage of caching. The cache line size is set to 512 by default. This greatly speeds up stack backtraces on MacOSX when using the ProcessGDBRemote process plug-in since only about 6300 packets per second can be sent. Initial speedups show: Prior to caching: 10,000 stack frames took 5.2 seconds After caching: 10,000 stack frames in 240 ms! About a 20x speedup! llvm-svn: 122996
2011-01-07 14:08:19 +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
size_t
Expose new read memory fucntion through python in SBProcess: size_t SBProcess::ReadCStringFromMemory (addr_t addr, void *buf, size_t size, lldb::SBError &error); uint64_t SBProcess::ReadUnsignedFromMemory (addr_t addr, uint32_t byte_size, lldb::SBError &error); lldb::addr_t SBProcess::ReadPointerFromMemory (addr_t addr, lldb::SBError &error); These ReadCStringFromMemory() has some SWIG type magic that makes it return the python string directly and the "buf" is not needed: error = SBError() max_cstr_len = 256 cstr = lldb.process.ReadCStringFromMemory (0x1000, max_cstr_len, error) if error.Success(): .... The other two functions behave as expteced. This will make it easier to get integer values from the inferior process that are correctly byte swapped. Also for pointers, the correct pointer byte size will be used. Also cleaned up a few printf style warnings for the 32 bit lldb build on darwin. llvm-svn: 146636
2011-12-15 11:14:23 +08:00
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)
{
Expose new read memory fucntion through python in SBProcess: size_t SBProcess::ReadCStringFromMemory (addr_t addr, void *buf, size_t size, lldb::SBError &error); uint64_t SBProcess::ReadUnsignedFromMemory (addr_t addr, uint32_t byte_size, lldb::SBError &error); lldb::addr_t SBProcess::ReadPointerFromMemory (addr_t addr, lldb::SBError &error); These ReadCStringFromMemory() has some SWIG type magic that makes it return the python string directly and the "buf" is not needed: error = SBError() max_cstr_len = 256 cstr = lldb.process.ReadCStringFromMemory (0x1000, max_cstr_len, error) if error.Success(): .... The other two functions behave as expteced. This will make it easier to get integer values from the inferior process that are correctly byte swapped. Also for pointers, the correct pointer byte size will be used. Also cleaned up a few printf style warnings for the 32 bit lldb build on darwin. llvm-svn: 146636
2011-12-15 11:14:23 +08:00
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)
{
Expose new read memory fucntion through python in SBProcess: size_t SBProcess::ReadCStringFromMemory (addr_t addr, void *buf, size_t size, lldb::SBError &error); uint64_t SBProcess::ReadUnsignedFromMemory (addr_t addr, uint32_t byte_size, lldb::SBError &error); lldb::addr_t SBProcess::ReadPointerFromMemory (addr_t addr, lldb::SBError &error); These ReadCStringFromMemory() has some SWIG type magic that makes it return the python string directly and the "buf" is not needed: error = SBError() max_cstr_len = 256 cstr = lldb.process.ReadCStringFromMemory (0x1000, max_cstr_len, error) if error.Success(): .... The other two functions behave as expteced. This will make it easier to get integer values from the inferior process that are correctly byte swapped. Also for pointers, the correct pointer byte size will be used. Also cleaned up a few printf style warnings for the 32 bit lldb build on darwin. llvm-svn: 146636
2011-12-15 11:14:23 +08:00
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;
}
}
Expose new read memory fucntion through python in SBProcess: size_t SBProcess::ReadCStringFromMemory (addr_t addr, void *buf, size_t size, lldb::SBError &error); uint64_t SBProcess::ReadUnsignedFromMemory (addr_t addr, uint32_t byte_size, lldb::SBError &error); lldb::addr_t SBProcess::ReadPointerFromMemory (addr_t addr, lldb::SBError &error); These ReadCStringFromMemory() has some SWIG type magic that makes it return the python string directly and the "buf" is not needed: error = SBError() max_cstr_len = 256 cstr = lldb.process.ReadCStringFromMemory (0x1000, max_cstr_len, error) if error.Success(): .... The other two functions behave as expteced. This will make it easier to get integer values from the inferior process that are correctly byte swapped. Also for pointers, the correct pointer byte size will be used. Also cleaned up a few printf style warnings for the 32 bit lldb build on darwin. llvm-svn: 146636
2011-12-15 11:14:23 +08:00
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;
}
Added memory caching to lldb_private::Process. All lldb_private::Process subclasses will automatically be able to take advantage of caching. The cache line size is set to 512 by default. This greatly speeds up stack backtraces on MacOSX when using the ProcessGDBRemote process plug-in since only about 6300 packets per second can be sent. Initial speedups show: Prior to caching: 10,000 stack frames took 5.2 seconds After caching: 10,000 stack frames in 240 ms! About a 20x speedup! llvm-svn: 122996
2011-01-07 14:08:19 +08:00
size_t
Process::ReadMemoryFromInferior (addr_t addr, void *buf, size_t size, Error &error)
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
{
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;
}
Added the ability to read unsigned integers from the Process: uint64_t Process::ReadUnsignedInteger (addr_t addr, size_t int_byte_size, Error &error); llvm-svn: 121996
2010-12-17 04:01:20 +08:00
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 the ability to read unsigned integers from the Process: uint64_t Process::ReadUnsignedInteger (addr_t addr, size_t int_byte_size, Error &error); llvm-svn: 121996
2010-12-17 04:01:20 +08:00
{
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;
Added the ability to read unsigned integers from the Process: uint64_t Process::ReadUnsignedInteger (addr_t addr, size_t int_byte_size, Error &error); llvm-svn: 121996
2010-12-17 04:01:20 +08:00
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;
Added the ability to read unsigned integers from the Process: uint64_t Process::ReadUnsignedInteger (addr_t addr, size_t int_byte_size, Error &error); llvm-svn: 121996
2010-12-17 04:01:20 +08:00
}
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
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)
{
Added memory caching to lldb_private::Process. All lldb_private::Process subclasses will automatically be able to take advantage of caching. The cache line size is set to 512 by default. This greatly speeds up stack backtraces on MacOSX when using the ProcessGDBRemote process plug-in since only about 6300 packets per second can be sent. Initial speedups show: Prior to caching: 10,000 stack frames took 5.2 seconds After caching: 10,000 stack frames in 240 ms! About a 20x speedup! llvm-svn: 122996
2011-01-07 14:08:19 +08:00
#if defined (ENABLE_MEMORY_CACHING)
m_memory_cache.Flush (addr, size);
#endif
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
if (buf == NULL || size == 0)
return 0;
Add support for "dynamic values" for C++ classes. This currently only works for "frame var" and for the expressions that are simple enough to get passed to the "frame var" underpinnings. The parser code will have to be changed to also query for the dynamic types & offsets as it is looking up variables. The behavior of "frame var" is controlled in two ways. You can pass "-d {true/false} to the frame var command to get the dynamic or static value of the variables you are printing. There's also a general setting: target.prefer-dynamic-value (boolean) = 'true' which is consulted if you call "frame var" without supplying a value for the -d option. llvm-svn: 129623
2011-04-16 08:01:13 +08:00
Move the handling of breakpoint conditions from the Private event loop to the StopInfoBreakpoint::DoActions, which happens as the event is removed. Also use the return value of asynchronous breakpoint callbacks, they get checked before, and override the breakpoint conditions. Added ProcessModInfo class, to unify "stop_id generation" and "memory modification generation", and use where needed. llvm-svn: 137102
2011-08-09 10:12:22 +08:00
m_mod_id.BumpMemoryID();
Add support for "dynamic values" for C++ classes. This currently only works for "frame var" and for the expressions that are simple enough to get passed to the "frame var" underpinnings. The parser code will have to be changed to also query for the dynamic types & offsets as it is looking up variables. The behavior of "frame var" is controlled in two ways. You can pass "-d {true/false} to the frame var command to get the dynamic or static value of the variables you are printing. There's also a general setting: target.prefer-dynamic-value (boolean) = 'true' which is consulted if you call "frame var" without supplying a value for the -d option. llvm-svn: 129623
2011-04-16 08:01:13 +08:00
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
// 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::collection::const_iterator iter = m_breakpoint_site_list.GetMap()->lower_bound (addr);
BreakpointSiteList::collection::const_iterator end = m_breakpoint_site_list.GetMap()->end();
if (iter == end || iter->second->GetLoadAddress() > addr + size)
Fixed an issue where large memory writes might not get chunked up into smaller packets in GDB remote. Also fixed a compiler warning for an unhandled case for a switch. llvm-svn: 131397
2011-05-16 10:35:02 +08:00
return WriteMemoryPrivate (addr, buf, size, error);
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
BreakpointSiteList::collection::const_iterator pos;
size_t bytes_written = 0;
Merged Eli Friedman's linux build changes where he added Makefile files that enabled LLVM make style building and made this compile LLDB on Mac OS X. We can now iterate on this to make the build work on both linux and macosx. llvm-svn: 108009
2010-07-10 04:39:50 +08:00
addr_t intersect_addr = 0;
size_t intersect_size = 0;
size_t opcode_offset = 0;
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
const uint8_t *ubuf = (const uint8_t *)buf;
for (pos = iter; pos != end; ++pos)
{
BreakpointSiteSP bp;
bp = pos->second;
assert(bp->IntersectsRange(addr, size, &intersect_addr, &intersect_size, &opcode_offset));
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.
break;
}
}
// 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;
}
// Write any remaining bytes after the last breakpoint if we have any left
if (bytes_written < size)
bytes_written += WriteMemoryPrivate (addr + bytes_written,
ubuf + bytes_written,
size - bytes_written,
error);
Add support for "dynamic values" for C++ classes. This currently only works for "frame var" and for the expressions that are simple enough to get passed to the "frame var" underpinnings. The parser code will have to be changed to also query for the dynamic types & offsets as it is looking up variables. The behavior of "frame var" is controlled in two ways. You can pass "-d {true/false} to the frame var command to get the dynamic or static value of the variables you are printing. There's also a general setting: target.prefer-dynamic-value (boolean) = 'true' which is consulted if you call "frame var" without supplying a value for the -d option. llvm-svn: 129623
2011-04-16 08:01:13 +08:00
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
return 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
<rdar://problem/13069948> Major fixed to allow reading files that are over 4GB. The main problems were that the DataExtractor was using 32 bit offsets as a data cursor, and since we mmap all of our object files we could run into cases where if we had a very large core file that was over 4GB, we were running into the 4GB boundary. So I defined a new "lldb::offset_t" which should be used for all file offsets. After making this change, I enabled warnings for data loss and for enexpected implicit conversions temporarily and found a ton of things that I fixed. Any functions that take an index internally, should use "size_t" for any indexes and also should return "size_t" for any sizes of collections. llvm-svn: 173463
2013-01-26 02:06:21 +08:00
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;
if (byte_size <= sizeof(uval))
{
size_t bytes_read = ReadMemory (addr, &uval, byte_size, error);
if (bytes_read == byte_size)
{
DataExtractor data (&uval, sizeof(uval), GetByteOrder(), GetAddressByteSize());
<rdar://problem/13069948> Major fixed to allow reading files that are over 4GB. The main problems were that the DataExtractor was using 32 bit offsets as a data cursor, and since we mmap all of our object files we could run into cases where if we had a very large core file that was over 4GB, we were running into the 4GB boundary. So I defined a new "lldb::offset_t" which should be used for all file offsets. After making this change, I enabled warnings for data loss and for enexpected implicit conversions temporarily and found a ton of things that I fixed. Any functions that take an index internally, should use "size_t" for any indexes and also should return "size_t" for any sizes of collections. llvm-svn: 173463
2013-01-26 02:06:21 +08:00
lldb::offset_t offset = 0;
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 <= 4)
scalar = data.GetMaxU32 (&offset, byte_size);
else
scalar = data.GetMaxU64 (&offset, byte_size);
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;
}
Added an allocated memory cache to avoid having to allocate memory over and over when running JITed expressions. The allocated memory cache will cache allocate memory a page at a time for each permission combination and divvy up the memory and hand it out in 16 byte increments. llvm-svn: 131453
2011-05-17 11:37:42 +08:00
#define USE_ALLOCATE_MEMORY_CACHE 1
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
addr_t
Process::AllocateMemory(size_t size, uint32_t permissions, Error &error)
{
Use the dyld_mode, image_infos & image_infos_count passed into the shared library notification function to update libraries rather than reading the whole all_imaage_infos structure every time we get notified. llvm-svn: 133448
2011-06-21 01:32:44 +08:00
if (GetPrivateState() != eStateStopped)
return LLDB_INVALID_ADDRESS;
Added an allocated memory cache to avoid having to allocate memory over and over when running JITed expressions. The allocated memory cache will cache allocate memory a page at a time for each permission combination and divvy up the memory and hand it out in 16 byte increments. llvm-svn: 131453
2011-05-17 11:37:42 +08:00
#if defined (USE_ALLOCATE_MEMORY_CACHE)
return m_allocated_memory_cache.AllocateMemory(size, permissions, error);
#else
Improved process logging for both lldb_private::Process and ProcessGDBRemote. llvm-svn: 124080
2011-01-24 03:58:49 +08:00
addr_t allocated_addr = DoAllocateMemory (size, permissions, error);
<rdar://problem/13521159> LLDB is crashing when logging is enabled from lldb-perf-clang. This has to do with the global destructor chain as the process and its threads are being torn down. All logging channels now make one and only one instance that is kept in a global pointer which is never freed. This guarantees that logging can correctly continue as the process tears itself down. llvm-svn: 178191
2013-03-28 07:08:40 +08:00
Log *log(lldb_private::GetLogIfAllCategoriesSet (LIBLLDB_LOG_PROCESS));
Improved process logging for both lldb_private::Process and ProcessGDBRemote. llvm-svn: 124080
2011-01-24 03:58:49 +08:00
if (log)
Resolve printf formatting warnings on Linux: - use macros from inttypes.h for format strings instead of OS-specific types Patch from Matt Kopec! llvm-svn: 168945
2012-11-30 05:49:15 +08:00
log->Printf("Process::AllocateMemory(size=%4zu, permissions=%s) => 0x%16.16" PRIx64 " (m_stop_id = %u m_memory_id = %u)",
Improved process logging for both lldb_private::Process and ProcessGDBRemote. llvm-svn: 124080
2011-01-24 03:58:49 +08:00
size,
Added an allocated memory cache to avoid having to allocate memory over and over when running JITed expressions. The allocated memory cache will cache allocate memory a page at a time for each permission combination and divvy up the memory and hand it out in 16 byte increments. llvm-svn: 131453
2011-05-17 11:37:42 +08:00
GetPermissionsAsCString (permissions),
Improved process logging for both lldb_private::Process and ProcessGDBRemote. llvm-svn: 124080
2011-01-24 03:58:49 +08:00
(uint64_t)allocated_addr,
Move the handling of breakpoint conditions from the Private event loop to the StopInfoBreakpoint::DoActions, which happens as the event is removed. Also use the return value of asynchronous breakpoint callbacks, they get checked before, and override the breakpoint conditions. Added ProcessModInfo class, to unify "stop_id generation" and "memory modification generation", and use where needed. llvm-svn: 137102
2011-08-09 10:12:22 +08:00
m_mod_id.GetStopID(),
m_mod_id.GetMemoryID());
Improved process logging for both lldb_private::Process and ProcessGDBRemote. llvm-svn: 124080
2011-01-24 03:58:49 +08:00
return allocated_addr;
Added an allocated memory cache to avoid having to allocate memory over and over when running JITed expressions. The allocated memory cache will cache allocate memory a page at a time for each permission combination and divvy up the memory and hand it out in 16 byte increments. llvm-svn: 131453
2011-05-17 11:37:42 +08:00
#endif
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
Fixed a problem where expressions would attempt to allocate memory in a process that did not support expression execution. Also improved detection of whether or not a process can execute expressions. llvm-svn: 140202
2011-09-21 07:01:51 +08:00
bool
Process::CanJIT ()
{
Only allow expressions to use the JIT if memory can be allocated in the process. llvm-svn: 150523
2012-02-15 06:50:38 +08:00
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);
}
Fixed a problem where expressions would attempt to allocate memory in a process that did not support expression execution. Also improved detection of whether or not a process can execute expressions. llvm-svn: 140202
2011-09-21 07:01:51 +08:00
return m_can_jit == eCanJITYes;
}
void
Process::SetCanJIT (bool can_jit)
{
m_can_jit = (can_jit ? eCanJITYes : eCanJITNo);
}
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
Error
Process::DeallocateMemory (addr_t ptr)
{
Added an allocated memory cache to avoid having to allocate memory over and over when running JITed expressions. The allocated memory cache will cache allocate memory a page at a time for each permission combination and divvy up the memory and hand it out in 16 byte increments. llvm-svn: 131453
2011-05-17 11:37:42 +08:00
Error error;
#if defined (USE_ALLOCATE_MEMORY_CACHE)
if (!m_allocated_memory_cache.DeallocateMemory(ptr))
{
Resolve printf formatting warnings on Linux: - use macros from inttypes.h for format strings instead of OS-specific types Patch from Matt Kopec! llvm-svn: 168945
2012-11-30 05:49:15 +08:00
error.SetErrorStringWithFormat ("deallocation of memory at 0x%" PRIx64 " failed.", (uint64_t)ptr);
Added an allocated memory cache to avoid having to allocate memory over and over when running JITed expressions. The allocated memory cache will cache allocate memory a page at a time for each permission combination and divvy up the memory and hand it out in 16 byte increments. llvm-svn: 131453
2011-05-17 11:37:42 +08:00
}
#else
error = DoDeallocateMemory (ptr);
Improved process logging for both lldb_private::Process and ProcessGDBRemote. llvm-svn: 124080
2011-01-24 03:58:49 +08:00
<rdar://problem/13521159> LLDB is crashing when logging is enabled from lldb-perf-clang. This has to do with the global destructor chain as the process and its threads are being torn down. All logging channels now make one and only one instance that is kept in a global pointer which is never freed. This guarantees that logging can correctly continue as the process tears itself down. llvm-svn: 178191
2013-03-28 07:08:40 +08:00
Log *log(lldb_private::GetLogIfAllCategoriesSet (LIBLLDB_LOG_PROCESS));
Improved process logging for both lldb_private::Process and ProcessGDBRemote. llvm-svn: 124080
2011-01-24 03:58:49 +08:00
if (log)
Resolve printf formatting warnings on Linux: - use macros from inttypes.h for format strings instead of OS-specific types Patch from Matt Kopec! llvm-svn: 168945
2012-11-30 05:49:15 +08:00
log->Printf("Process::DeallocateMemory(addr=0x%16.16" PRIx64 ") => err = %s (m_stop_id = %u, m_memory_id = %u)",
Improved process logging for both lldb_private::Process and ProcessGDBRemote. llvm-svn: 124080
2011-01-24 03:58:49 +08:00
ptr,
error.AsCString("SUCCESS"),
Move the handling of breakpoint conditions from the Private event loop to the StopInfoBreakpoint::DoActions, which happens as the event is removed. Also use the return value of asynchronous breakpoint callbacks, they get checked before, and override the breakpoint conditions. Added ProcessModInfo class, to unify "stop_id generation" and "memory modification generation", and use where needed. llvm-svn: 137102
2011-08-09 10:12:22 +08:00
m_mod_id.GetStopID(),
m_mod_id.GetMemoryID());
Added an allocated memory cache to avoid having to allocate memory over and over when running JITed expressions. The allocated memory cache will cache allocate memory a page at a time for each permission combination and divvy up the memory and hand it out in 16 byte increments. llvm-svn: 131453
2011-05-17 11:37:42 +08:00
#endif
Improved process logging for both lldb_private::Process and ProcessGDBRemote. llvm-svn: 124080
2011-01-24 03:58:49 +08:00
return error;
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
Follow up on <rdar://12720514>. Removed commented out code. llvm-svn: 168232
2012-11-17 08:33:14 +08:00
<rdar://problem/10560053> Fixed "target modules list" (aliased to "image list") to output more information by default. Modified the "target modules list" to have a few new options: "--header" or "-h" => show the image header address "--offset" or "-o" => show the image header address offset from the address in the file (the slide applied to the shared library) Removed the "--symfile-basename" or "-S" option, and repurposed it to "--symfile-unique" "-S" which will show the symbol file if it differs from the executable file. ObjectFile's can now be loaded from memory for cases where we don't have the files cached locally in an SDK or net mounted root. ObjectFileMachO can now read mach files from memory. Moved the section data reading code into the ObjectFile so that the object file can get the section data from Process memory if the file is only in memory. lldb_private::Module can now load its object file in a target with a rigid slide (very common operation for most dynamic linkers) by using: bool Module::SetLoadAddress (Target &target, lldb::addr_t offset, bool &changed) lldb::SBModule() now has a new constructor in the public interface: SBModule::SBModule (lldb::SBProcess &process, lldb::addr_t header_addr); This will find an appropriate ObjectFile plug-in to load an image from memory where the object file header is at "header_addr". llvm-svn: 149804
2012-02-05 10:38:54 +08:00
ModuleSP
Full core file support has been added for mach-o core files. Tracking modules down when you have a UUID and a path has been improved. DynamicLoaderDarwinKernel no longer parses mach-o load commands and it now uses the memory based modules now that we can load modules from memory. Added a target setting named "target.exec-search-paths" which can be used to supply a list of directories to use when trying to look for executables. This allows one or more directories to be used when searching for modules that may not exist in the SDK/PDK. The target automatically adds the directory for the main executable to this list so this should help us in tracking down shared libraries and other binaries. llvm-svn: 150426
2012-02-14 07:10:39 +08:00
Process::ReadModuleFromMemory (const FileSpec& file_spec,
<rdar://problem/13092722> Fix in loading mach files from memory when using DynamicLoaderMacOSXDYLD. Removed the uuid mismatch warning that could be spit out and any time during debugging and removed the test case that was looking for that. Currently the "add-dsym" or "target symbols add" command will report an error when the UUID's don't match. Be more careful when checking and resolving section + offset addresses to make sure none of the base addresses are invalid. llvm-svn: 174222
2013-02-02 05:38:35 +08:00
lldb::addr_t header_addr)
<rdar://problem/10560053> Fixed "target modules list" (aliased to "image list") to output more information by default. Modified the "target modules list" to have a few new options: "--header" or "-h" => show the image header address "--offset" or "-o" => show the image header address offset from the address in the file (the slide applied to the shared library) Removed the "--symfile-basename" or "-S" option, and repurposed it to "--symfile-unique" "-S" which will show the symbol file if it differs from the executable file. ObjectFile's can now be loaded from memory for cases where we don't have the files cached locally in an SDK or net mounted root. ObjectFileMachO can now read mach files from memory. Moved the section data reading code into the ObjectFile so that the object file can get the section data from Process memory if the file is only in memory. lldb_private::Module can now load its object file in a target with a rigid slide (very common operation for most dynamic linkers) by using: bool Module::SetLoadAddress (Target &target, lldb::addr_t offset, bool &changed) lldb::SBModule() now has a new constructor in the public interface: SBModule::SBModule (lldb::SBProcess &process, lldb::addr_t header_addr); This will find an appropriate ObjectFile plug-in to load an image from memory where the object file header is at "header_addr". llvm-svn: 149804
2012-02-05 10:38:54 +08:00
{
Fixed a crasher that was happening after making ObjectFile objects have a weak reference back to the Module. We were crashing when trying to make a memory object file since it was trying to get the object in the Module constructor before the "Module *" had been put into a shared pointer, and the module was trying to initialize a weak pointer back to it. llvm-svn: 151397
2012-02-25 05:55:59 +08:00
ModuleSP module_sp (new Module (file_spec, ArchSpec()));
<rdar://problem/10560053> Fixed "target modules list" (aliased to "image list") to output more information by default. Modified the "target modules list" to have a few new options: "--header" or "-h" => show the image header address "--offset" or "-o" => show the image header address offset from the address in the file (the slide applied to the shared library) Removed the "--symfile-basename" or "-S" option, and repurposed it to "--symfile-unique" "-S" which will show the symbol file if it differs from the executable file. ObjectFile's can now be loaded from memory for cases where we don't have the files cached locally in an SDK or net mounted root. ObjectFileMachO can now read mach files from memory. Moved the section data reading code into the ObjectFile so that the object file can get the section data from Process memory if the file is only in memory. lldb_private::Module can now load its object file in a target with a rigid slide (very common operation for most dynamic linkers) by using: bool Module::SetLoadAddress (Target &target, lldb::addr_t offset, bool &changed) lldb::SBModule() now has a new constructor in the public interface: SBModule::SBModule (lldb::SBProcess &process, lldb::addr_t header_addr); This will find an appropriate ObjectFile plug-in to load an image from memory where the object file header is at "header_addr". llvm-svn: 149804
2012-02-05 10:38:54 +08:00
if (module_sp)
{
Fixed a crasher that was happening after making ObjectFile objects have a weak reference back to the Module. We were crashing when trying to make a memory object file since it was trying to get the object in the Module constructor before the "Module *" had been put into a shared pointer, and the module was trying to initialize a weak pointer back to it. llvm-svn: 151397
2012-02-25 05:55:59 +08:00
Error error;
ObjectFile *objfile = module_sp->GetMemoryObjectFile (shared_from_this(), header_addr, error);
if (objfile)
return module_sp;
<rdar://problem/10560053> Fixed "target modules list" (aliased to "image list") to output more information by default. Modified the "target modules list" to have a few new options: "--header" or "-h" => show the image header address "--offset" or "-o" => show the image header address offset from the address in the file (the slide applied to the shared library) Removed the "--symfile-basename" or "-S" option, and repurposed it to "--symfile-unique" "-S" which will show the symbol file if it differs from the executable file. ObjectFile's can now be loaded from memory for cases where we don't have the files cached locally in an SDK or net mounted root. ObjectFileMachO can now read mach files from memory. Moved the section data reading code into the ObjectFile so that the object file can get the section data from Process memory if the file is only in memory. lldb_private::Module can now load its object file in a target with a rigid slide (very common operation for most dynamic linkers) by using: bool Module::SetLoadAddress (Target &target, lldb::addr_t offset, bool &changed) lldb::SBModule() now has a new constructor in the public interface: SBModule::SBModule (lldb::SBProcess &process, lldb::addr_t header_addr); This will find an appropriate ObjectFile plug-in to load an image from memory where the object file header is at "header_addr". llvm-svn: 149804
2012-02-05 10:38:54 +08:00
}
Fixed a crasher that was happening after making ObjectFile objects have a weak reference back to the Module. We were crashing when trying to make a memory object file since it was trying to get the object in the Module constructor before the "Module *" had been put into a shared pointer, and the module was trying to initialize a weak pointer back to it. llvm-svn: 151397
2012-02-25 05:55:59 +08:00
return ModuleSP();
<rdar://problem/10560053> Fixed "target modules list" (aliased to "image list") to output more information by default. Modified the "target modules list" to have a few new options: "--header" or "-h" => show the image header address "--offset" or "-o" => show the image header address offset from the address in the file (the slide applied to the shared library) Removed the "--symfile-basename" or "-S" option, and repurposed it to "--symfile-unique" "-S" which will show the symbol file if it differs from the executable file. ObjectFile's can now be loaded from memory for cases where we don't have the files cached locally in an SDK or net mounted root. ObjectFileMachO can now read mach files from memory. Moved the section data reading code into the ObjectFile so that the object file can get the section data from Process memory if the file is only in memory. lldb_private::Module can now load its object file in a target with a rigid slide (very common operation for most dynamic linkers) by using: bool Module::SetLoadAddress (Target &target, lldb::addr_t offset, bool &changed) lldb::SBModule() now has a new constructor in the public interface: SBModule::SBModule (lldb::SBProcess &process, lldb::addr_t header_addr); This will find an appropriate ObjectFile plug-in to load an image from memory where the object file header is at "header_addr". llvm-svn: 149804
2012-02-05 10:38:54 +08:00
}
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
Error
Adding events when watchpoints are set or changed. <rdar://problem/11597849> llvm-svn: 170400
2012-12-18 10:03:49 +08:00
Process::EnableWatchpoint (Watchpoint *watchpoint, bool notify)
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
{
Error error;
error.SetErrorString("watchpoints are not supported");
return error;
}
Error
Adding events when watchpoints are set or changed. <rdar://problem/11597849> llvm-svn: 170400
2012-12-18 10:03:49 +08:00
Process::DisableWatchpoint (Watchpoint *watchpoint, bool notify)
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
{
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)
{
Fixed an issue in "SBError SBProcess::Destroy ()" where it wasn't properly checking the validity of the shared pointer prior to using it. Fixed the GDB remote plug-in to once again watch for a reply from the "k" packet, and fixed the logic to make sure the thread requesting the kill and the async thread play nice (and very quickly) by synchronizing the packet sending and reply. I also tweaked some of the shut down packet ("k" kill, "D" detach, and the halt packet) to make sure they do the right thing. Fixed "StateType Process::WaitForProcessStopPrivate (...)" to correctly pass the timeout along to WaitForStateChangedEventsPrivate() and made the function behave correctly with respect to timing out. Added separate STDIN, STDOUT, and STDERR support to debugserver. Also added the start of being able to set the working directory for the inferior process. llvm-svn: 124049
2011-01-23 07:43:18 +08:00
event_sp.reset();
state = WaitForStateChangedEventsPrivate (timeout, event_sp);
Fixed an issue with the pthread_setspecific() where we weren't NULL-ing out the thread specific data and were destroying the thread specfic data more than once. Also added the ability to ask a lldb::StateType if it is stopped with an additional paramter of "must_exist" which means that the state must be a stopped state for a process that still exists. This means that eStateExited and eStateUnloaded will no longer return true if "must_exist" is set to true. llvm-svn: 144875
2011-11-17 09:23:07 +08:00
if (StateIsStoppedState(state, false))
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
break;
Fixed an issue in "SBError SBProcess::Destroy ()" where it wasn't properly checking the validity of the shared pointer prior to using it. Fixed the GDB remote plug-in to once again watch for a reply from the "k" packet, and fixed the logic to make sure the thread requesting the kill and the async thread play nice (and very quickly) by synchronizing the packet sending and reply. I also tweaked some of the shut down packet ("k" kill, "D" detach, and the halt packet) to make sure they do the right thing. Fixed "StateType Process::WaitForProcessStopPrivate (...)" to correctly pass the timeout along to WaitForStateChangedEventsPrivate() and made the function behave correctly with respect to timing out. Added separate STDIN, STDOUT, and STDERR support to debugserver. Also added the start of being able to set the working directory for the inferior process. llvm-svn: 124049
2011-01-23 07:43:18 +08:00
// If state is invalid, then we timed out
if (state == eStateInvalid)
break;
if (event_sp)
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
HandlePrivateEvent (event_sp);
}
return state;
}
Error
Modified all Process::Launch() calls to use a ProcessLaunchInfo structure on internal only (public API hasn't changed) to simplify the paramter list to the launch calls down into just one argument. Also all of the argument, envronment and stdio things are now handled in a much more centralized fashion. llvm-svn: 143656
2011-11-04 05:22:33 +08:00
Process::Launch (const ProcessLaunchInfo &launch_info)
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
{
Error error;
m_abi_sp.reset();
The DynamicLoader plug-in instance now lives up in lldb_private::Process where it should live and the lldb_private::Process takes care of managing the auto pointer to the dynamic loader instance. Also, now that the ArchSpec contains the target triple, we are able to correctly set the Target architecture in DidLaunch/DidAttach in the subclasses, and then the lldb_private::Process will find the dynamic loader plug-in by letting the dynamic loader plug-ins inspect the arch/triple in the target. So now the ProcessGDBRemote plug-in is another step closer to be purely process/platform agnostic. I updated the ProcessMacOSX and the ProcessLinux plug-ins accordingly. llvm-svn: 125650
2011-02-16 12:46:07 +08:00
m_dyld_ap.reset();
Added a new plug-in type: lldb_private::OperatingSystem. The operating system plug-ins are add on plug-ins for the lldb_private::Process class that can add thread contexts that are read from memory. It is common in kernels to have a lot of threads that are not currently executing on any cores (JTAG debugging also follows this sort of thing) and are context switched out whose state is stored in memory data structures. Clients can now subclass the OperatingSystem plug-ins and then make sure their Create functions correcltly only enable themselves when the right binary/target triple are being debugged. The operating system plug-ins get a chance to attach themselves to processes just after launching or attaching and are given a lldb_private::Process object pointer which can be inspected to see if the main executable, target triple, or any shared libraries match a case where the OS plug-in should be used. Currently the OS plug-ins can create new threads, define the register contexts for these threads (which can all be different if desired), and populate and manage the thread info (stop reason, registers in the register context) as the debug session goes on. llvm-svn: 138228
2011-08-22 10:49:39 +08:00
m_os_ap.reset();
Make processes use InputReaders for their input. Move the process ReadThread stuff into the main Process class (out of the Process Plugins). This has the (intended) side effect of disabling the command line tool from reading input/commands while the process is running (the input is directed to the running process rather than to the command interpreter). llvm-svn: 119329
2010-11-16 13:07:41 +08:00
m_process_input_reader.reset();
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
Added the ability to remove orphaned module shared pointers from a ModuleList. This is helping us track down some extra references to ModuleSP objects that are causing things to get kept around for too long. Added a module pointer accessor to target and change a lot of code to use it where it would be more efficient. "taret delete" can now specify "--clean=1" which will cleanup the global module list for any orphaned module in the shared module cache which can save memory and also help track down module reference leaks like we have now. llvm-svn: 137294
2011-08-11 10:48:45 +08:00
Module *exe_module = m_target.GetExecutableModulePointer();
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
if (exe_module)
{
Added the ability to set the Platform path for a module through the SBModule interface. Added a quick way to set the platform though the SBDebugger interface. I will actually an a SBPlatform support soon, but for now this will do. ConnectionFileDescriptor can be passed a url formatted as: "fd://<fd>" where <fd> is a file descriptor in the current process. This is handy if you have services, deamons, or other tools that can spawn processes and give you a file handle. llvm-svn: 130565
2011-04-30 09:09:13 +08:00
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));
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
if (exe_module->GetFileSpec().Exists())
{
Fixed CommandReturnObject::SetImmediateErrorFile() to set the correct stream. Modifed lldb_private::Process to be able to handle connecting to a remote target that isn't running a process. This leaves lldb_private::Process in the eStateConnected state from which we can then do an attach or launch. Modified ProcessGDBRemote to be able to set stdin, stdout, stderr, working dir, disable ASLR and a few other settings down by using new GDB remote packets. This allows us to keep all of our current launch flags and settings intact and still be able to communicate them over to the remote GDB server. Previously these were being sent as arguments to the debugserver binary that we were spawning. Also modified ProcessGDBRemote to handle losing connection to the remote GDB server and always exit immediately. We do this by watching the lldb_private::Communication event bit for the read thread exiting in the ProcessGDBRemote async thread. Added support for many of the new 'Q' packets for setting stdin, stdout, stderr, working dir and disable ASLR to the GDBRemoteCommunication class for easy accesss. Modified debugserver for all of the new 'Q' packets and also made it so that debugserver always exists if it loses connection with the remote debugger. llvm-svn: 126444
2011-02-25 06:24:29 +08:00
if (PrivateStateThreadIsValid ())
PausePrivateStateThread ();
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
error = WillLaunch (exe_module);
if (error.Success())
{
Cleaned up the SWIG stuff so all includes happen as they should, no pulling tricks to get types to resolve. I did this by correctly including the correct files: stdint.h and all lldb-*.h files first before including the API files. This allowed me to remove all of the hacks that were in the lldb.swig file and it also allows all of the #defines in lldb-defines.h and enumerations in lldb-enumerations.h to appear in the lldb.py module. This will make the python script code a lot more readable. Cleaned up the "process launch" command to not execute a "process continue" command, it now just does what it should have with the internal API calls instead of executing another command line command. Made the lldb_private::Process set the state to launching and attaching if WillLaunch/WillAttach return no error respectively. llvm-svn: 115902
2010-10-07 12:19:01 +08:00
SetPublicState (eStateLaunching);
Fixed the issue that was causing our monitor process threads to crash, it turned out to be unitialized data in the ProcessLaunchInfo default constructor. Turning on MallocScribble in the environment helped track this down. When we launch and attach using the host layer, we now inform the process that it shouldn't detach when by calling an accessor. llvm-svn: 144882
2011-11-17 12:46:02 +08:00
m_should_detach = false;
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
Modified patch from Matt Kopec that fixes a process launch issue on linux where we wouldn't acquire the process run lock. llvm-svn: 163163
2012-09-05 04:29:05 +08:00
if (m_run_lock.WriteTryLock())
{
// Now launch using these arguments.
error = DoLaunch (exe_module, launch_info);
}
else
{
// This shouldn't happen
error.SetErrorString("failed to acquire process run lock");
}
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
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;
Add a 10 second timeout to ensure that we don't lock up if we never get to the process entry point. llvm-svn: 133598
2011-06-22 09:42:17 +08:00
TimeValue timeout_time;
timeout_time = TimeValue::Now();
timeout_time.OffsetWithSeconds(10);
StateType state = WaitForProcessStopPrivate(&timeout_time, event_sp);
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
Add a 10 second timeout to ensure that we don't lock up if we never get to the process entry point. llvm-svn: 133598
2011-06-22 09:42:17 +08:00
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)
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
{
The DynamicLoader plug-in instance now lives up in lldb_private::Process where it should live and the lldb_private::Process takes care of managing the auto pointer to the dynamic loader instance. Also, now that the ArchSpec contains the target triple, we are able to correctly set the Target architecture in DidLaunch/DidAttach in the subclasses, and then the lldb_private::Process will find the dynamic loader plug-in by letting the dynamic loader plug-ins inspect the arch/triple in the target. So now the ProcessGDBRemote plug-in is another step closer to be purely process/platform agnostic. I updated the ProcessMacOSX and the ProcessLinux plug-ins accordingly. llvm-svn: 125650
2011-02-16 12:46:07 +08:00
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
DidLaunch ();
Full core file support has been added for mach-o core files. Tracking modules down when you have a UUID and a path has been improved. DynamicLoaderDarwinKernel no longer parses mach-o load commands and it now uses the memory based modules now that we can load modules from memory. Added a target setting named "target.exec-search-paths" which can be used to supply a list of directories to use when trying to look for executables. This allows one or more directories to be used when searching for modules that may not exist in the SDK/PDK. The target automatically adds the directory for the main executable to this list so this should help us in tracking down shared libraries and other binaries. llvm-svn: 150426
2012-02-14 07:10:39 +08:00
DynamicLoader *dyld = GetDynamicLoader ();
if (dyld)
dyld->DidLaunch();
The DynamicLoader plug-in instance now lives up in lldb_private::Process where it should live and the lldb_private::Process takes care of managing the auto pointer to the dynamic loader instance. Also, now that the ArchSpec contains the target triple, we are able to correctly set the Target architecture in DidLaunch/DidAttach in the subclasses, and then the lldb_private::Process will find the dynamic loader plug-in by letting the dynamic loader plug-ins inspect the arch/triple in the target. So now the ProcessGDBRemote plug-in is another step closer to be purely process/platform agnostic. I updated the ProcessMacOSX and the ProcessLinux plug-ins accordingly. llvm-svn: 125650
2011-02-16 12:46:07 +08:00
Added a new plug-in type: lldb_private::OperatingSystem. The operating system plug-ins are add on plug-ins for the lldb_private::Process class that can add thread contexts that are read from memory. It is common in kernels to have a lot of threads that are not currently executing on any cores (JTAG debugging also follows this sort of thing) and are context switched out whose state is stored in memory data structures. Clients can now subclass the OperatingSystem plug-ins and then make sure their Create functions correcltly only enable themselves when the right binary/target triple are being debugged. The operating system plug-ins get a chance to attach themselves to processes just after launching or attaching and are given a lldb_private::Process object pointer which can be inspected to see if the main executable, target triple, or any shared libraries match a case where the OS plug-in should be used. Currently the OS plug-ins can create new threads, define the register contexts for these threads (which can all be different if desired), and populate and manage the thread info (stop reason, registers in the register context) as the debug session goes on. llvm-svn: 138228
2011-08-22 10:49:39 +08:00
m_os_ap.reset (OperatingSystem::FindPlugin (this, NULL));
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
// This delays passing the stopped event to listeners till DidLaunch gets
// a chance to complete...
HandlePrivateEvent (event_sp);
Fixed CommandReturnObject::SetImmediateErrorFile() to set the correct stream. Modifed lldb_private::Process to be able to handle connecting to a remote target that isn't running a process. This leaves lldb_private::Process in the eStateConnected state from which we can then do an attach or launch. Modified ProcessGDBRemote to be able to set stdin, stdout, stderr, working dir, disable ASLR and a few other settings down by using new GDB remote packets. This allows us to keep all of our current launch flags and settings intact and still be able to communicate them over to the remote GDB server. Previously these were being sent as arguments to the debugserver binary that we were spawning. Also modified ProcessGDBRemote to handle losing connection to the remote GDB server and always exit immediately. We do this by watching the lldb_private::Communication event bit for the read thread exiting in the ProcessGDBRemote async thread. Added support for many of the new 'Q' packets for setting stdin, stdout, stderr, working dir and disable ASLR to the GDBRemoteCommunication class for easy accesss. Modified debugserver for all of the new 'Q' packets and also made it so that debugserver always exists if it loses connection with the remote debugger. llvm-svn: 126444
2011-02-25 06:24:29 +08:00
if (PrivateStateThreadIsValid ())
ResumePrivateStateThread ();
else
StartPrivateStateThread ();
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
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
{
Cleaned up many error codes. For any who is filling in error strings into lldb_private::Error objects the rules are: - short strings that don't start with a capitol letter unless the name is a class or anything else that is always capitolized - no trailing newline character - should be one line if possible Implemented a first pass at adding "--gdb-format" support to anything that accepts format with optional size/count. llvm-svn: 142999
2011-10-26 08:56:27 +08:00
error.SetErrorStringWithFormat("file doesn't exist: '%s'", local_exec_file_path);
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
}
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 ();
Full core file support has been added for mach-o core files. Tracking modules down when you have a UUID and a path has been improved. DynamicLoaderDarwinKernel no longer parses mach-o load commands and it now uses the memory based modules now that we can load modules from memory. Added a target setting named "target.exec-search-paths" which can be used to supply a list of directories to use when trying to look for executables. This allows one or more directories to be used when searching for modules that may not exist in the SDK/PDK. The target automatically adds the directory for the main executable to this list so this should help us in tracking down shared libraries and other binaries. llvm-svn: 150426
2012-02-14 07:10:39 +08:00
DynamicLoader *dyld = GetDynamicLoader ();
if (dyld)
dyld->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;
}
Full core file support has been added for mach-o core files. Tracking modules down when you have a UUID and a path has been improved. DynamicLoaderDarwinKernel no longer parses mach-o load commands and it now uses the memory based modules now that we can load modules from memory. Added a target setting named "target.exec-search-paths" which can be used to supply a list of directories to use when trying to look for executables. This allows one or more directories to be used when searching for modules that may not exist in the SDK/PDK. The target automatically adds the directory for the main executable to this list so this should help us in tracking down shared libraries and other binaries. llvm-svn: 150426
2012-02-14 07:10:39 +08:00
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
Added a completion action class to the Process events so that we can make things like Attach and later Launch start their job, and then return to the event loop while waiting for the work to be done. llvm-svn: 124520
2011-01-29 09:49:25 +08:00
Process::NextEventAction::EventActionResult
Process::AttachCompletionHandler::PerformAction (lldb::EventSP &event_sp)
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
{
Added a completion action class to the Process events so that we can make things like Attach and later Launch start their job, and then return to the event loop while waiting for the work to be done. llvm-svn: 124520
2011-01-29 09:49:25 +08:00
StateType state = ProcessEventData::GetStateFromEvent (event_sp.get());
switch (state)
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
{
Finished up the async attach support. This allows us to request to attach by name or by pid (with or without waiting for a process to launch) and catch the response asynchronously. llvm-svn: 124530
2011-01-29 15:10:55 +08:00
case eStateRunning:
Fixed CommandReturnObject::SetImmediateErrorFile() to set the correct stream. Modifed lldb_private::Process to be able to handle connecting to a remote target that isn't running a process. This leaves lldb_private::Process in the eStateConnected state from which we can then do an attach or launch. Modified ProcessGDBRemote to be able to set stdin, stdout, stderr, working dir, disable ASLR and a few other settings down by using new GDB remote packets. This allows us to keep all of our current launch flags and settings intact and still be able to communicate them over to the remote GDB server. Previously these were being sent as arguments to the debugserver binary that we were spawning. Also modified ProcessGDBRemote to handle losing connection to the remote GDB server and always exit immediately. We do this by watching the lldb_private::Communication event bit for the read thread exiting in the ProcessGDBRemote async thread. Added support for many of the new 'Q' packets for setting stdin, stdout, stderr, working dir and disable ASLR to the GDBRemoteCommunication class for easy accesss. Modified debugserver for all of the new 'Q' packets and also made it so that debugserver always exists if it loses connection with the remote debugger. llvm-svn: 126444
2011-02-25 06:24:29 +08:00
case eStateConnected:
Finished up the async attach support. This allows us to request to attach by name or by pid (with or without waiting for a process to launch) and catch the response asynchronously. llvm-svn: 124530
2011-01-29 15:10:55 +08:00
return eEventActionRetry;
case eStateStopped:
case eStateCrashed:
Added the ability to run a process in a shell on MacOSX currently when using the --tty option. So you can now get shell expansion and file redirection: (lldb) process launch --tty --shell -- *.jpg < in.txt > out.txt Again, the "--tty" is mandatory for now until we hook this up to other functions. The shell is also currently hard coded to "/bin/bash" and not the "SHELL" variable. "/bin/tcsh" was causing problems which I need to dig into. llvm-svn: 144443
2011-11-12 10:10:56 +08:00
{
// During attach, prior to sending the eStateStopped event,
Make sure that DoResume doesn't stall if we shut down the async thread while DoResume is waiting for packet confirmation. Also added a bit more logging. Also, unlock the writer end of the run lock in Process.cpp on our way out of the private state thread so that the Process can shut down cleanly. <rdar://problem/11228538> llvm-svn: 154601
2012-04-13 02:49:31 +08:00
// lldb_private::Process subclasses must set the new process ID.
Added the ability to run a process in a shell on MacOSX currently when using the --tty option. So you can now get shell expansion and file redirection: (lldb) process launch --tty --shell -- *.jpg < in.txt > out.txt Again, the "--tty" is mandatory for now until we hook this up to other functions. The shell is also currently hard coded to "/bin/bash" and not the "SHELL" variable. "/bin/tcsh" was causing problems which I need to dig into. llvm-svn: 144443
2011-11-12 10:10:56 +08:00
assert (m_process->GetID() != LLDB_INVALID_PROCESS_ID);
if (m_exec_count > 0)
{
--m_exec_count;
Switch to setting the write side of the run lock when we call Resume. Then make a PrivateResume that doesn't switch the run-lock state, and use that where we are resuming without changing the public resume state. llvm-svn: 155092
2012-04-19 09:40:33 +08:00
m_process->PrivateResume ();
Process::Destroy should Halt before it tries to destroy so we don't have race conditions where we are in the middle of trying to service an event when we go to Destroy. The AttachCompletionHandler should note that it has restarted the target if it indeed does so. llvm-svn: 157327
2012-05-23 23:46:31 +08:00
Process::ProcessEventData::SetRestartedInEvent (event_sp.get(), true);
Added the ability to run a process in a shell on MacOSX currently when using the --tty option. So you can now get shell expansion and file redirection: (lldb) process launch --tty --shell -- *.jpg < in.txt > out.txt Again, the "--tty" is mandatory for now until we hook this up to other functions. The shell is also currently hard coded to "/bin/bash" and not the "SHELL" variable. "/bin/tcsh" was causing problems which I need to dig into. llvm-svn: 144443
2011-11-12 10:10:56 +08:00
return eEventActionRetry;
}
else
{
m_process->CompleteAttach ();
return eEventActionSuccess;
}
}
Finished up the async attach support. This allows us to request to attach by name or by pid (with or without waiting for a process to launch) and catch the response asynchronously. llvm-svn: 124530
2011-01-29 15:10:55 +08:00
break;
Added the ability to run a process in a shell on MacOSX currently when using the --tty option. So you can now get shell expansion and file redirection: (lldb) process launch --tty --shell -- *.jpg < in.txt > out.txt Again, the "--tty" is mandatory for now until we hook this up to other functions. The shell is also currently hard coded to "/bin/bash" and not the "SHELL" variable. "/bin/tcsh" was causing problems which I need to dig into. llvm-svn: 144443
2011-11-12 10:10:56 +08:00
Finished up the async attach support. This allows us to request to attach by name or by pid (with or without waiting for a process to launch) and catch the response asynchronously. llvm-svn: 124530
2011-01-29 15:10:55 +08:00
default:
case eStateExited:
case eStateInvalid:
break;
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
Added the ability to run a process in a shell on MacOSX currently when using the --tty option. So you can now get shell expansion and file redirection: (lldb) process launch --tty --shell -- *.jpg < in.txt > out.txt Again, the "--tty" is mandatory for now until we hook this up to other functions. The shell is also currently hard coded to "/bin/bash" and not the "SHELL" variable. "/bin/tcsh" was causing problems which I need to dig into. llvm-svn: 144443
2011-11-12 10:10:56 +08:00
m_exit_string.assign ("No valid Process");
return eEventActionExit;
Added a completion action class to the Process events so that we can make things like Attach and later Launch start their job, and then return to the event loop while waiting for the work to be done. llvm-svn: 124520
2011-01-29 09:49:25 +08:00
}
Process::NextEventAction::EventActionResult
Process::AttachCompletionHandler::HandleBeingInterrupted()
{
return eEventActionSuccess;
}
const char *
Process::AttachCompletionHandler::GetExitString ()
{
return m_exit_string.c_str();
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
Error
Added a new class to Process.h: ProcessAttachInfo. This class contains enough info for us to attach by pid, or by name and will also allow us to eventually do a lot more powerful attaches. If you look at the options for the "platform process list" command, there are many options which we should be able to specify. This will allow us to do things like "attach to a process named 'tcsh' that has a parent process ID of 123", or "attach to a process named 'x' which has an effective user ID of 345". I finished up the --shell implementation so that it can be used without the --tty option in "process launch". The "--shell" option now can take an optional argument which is the path to the shell to use (or a partial name like "sh" which we will find using the current PATH environment variable). Modified the Process::Attach to use the new ProcessAttachInfo as the sole argument and centralized a lot of code that was in the "process attach" Execute function so that everyone can take advantage of the powerful new attach functionality. llvm-svn: 144615
2011-11-15 11:53:30 +08:00
Process::Attach (ProcessAttachInfo &attach_info)
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
{
m_abi_sp.reset();
Make processes use InputReaders for their input. Move the process ReadThread stuff into the main Process class (out of the Process Plugins). This has the (intended) side effect of disabling the command line tool from reading input/commands while the process is running (the input is directed to the running process rather than to the command interpreter). llvm-svn: 119329
2010-11-16 13:07:41 +08:00
m_process_input_reader.reset();
The DynamicLoader plug-in instance now lives up in lldb_private::Process where it should live and the lldb_private::Process takes care of managing the auto pointer to the dynamic loader instance. Also, now that the ArchSpec contains the target triple, we are able to correctly set the Target architecture in DidLaunch/DidAttach in the subclasses, and then the lldb_private::Process will find the dynamic loader plug-in by letting the dynamic loader plug-ins inspect the arch/triple in the target. So now the ProcessGDBRemote plug-in is another step closer to be purely process/platform agnostic. I updated the ProcessMacOSX and the ProcessLinux plug-ins accordingly. llvm-svn: 125650
2011-02-16 12:46:07 +08:00
m_dyld_ap.reset();
Added a new plug-in type: lldb_private::OperatingSystem. The operating system plug-ins are add on plug-ins for the lldb_private::Process class that can add thread contexts that are read from memory. It is common in kernels to have a lot of threads that are not currently executing on any cores (JTAG debugging also follows this sort of thing) and are context switched out whose state is stored in memory data structures. Clients can now subclass the OperatingSystem plug-ins and then make sure their Create functions correcltly only enable themselves when the right binary/target triple are being debugged. The operating system plug-ins get a chance to attach themselves to processes just after launching or attaching and are given a lldb_private::Process object pointer which can be inspected to see if the main executable, target triple, or any shared libraries match a case where the OS plug-in should be used. Currently the OS plug-ins can create new threads, define the register contexts for these threads (which can all be different if desired), and populate and manage the thread info (stop reason, registers in the register context) as the debug session goes on. llvm-svn: 138228
2011-08-22 10:49:39 +08:00
m_os_ap.reset();
Change Target & Process so they can really be initialized with an invalid architecture. Arrange that this then gets properly set on attach, or when a "file" is set. Add a completer for "process attach -n". Caveats: there isn't currently a way to handle multiple processes with the same name. That will have to wait on a way to pass annotations along with the completion strings. llvm-svn: 110624
2010-08-10 07:31:02 +08:00
Added a new class to Process.h: ProcessAttachInfo. This class contains enough info for us to attach by pid, or by name and will also allow us to eventually do a lot more powerful attaches. If you look at the options for the "platform process list" command, there are many options which we should be able to specify. This will allow us to do things like "attach to a process named 'tcsh' that has a parent process ID of 123", or "attach to a process named 'x' which has an effective user ID of 345". I finished up the --shell implementation so that it can be used without the --tty option in "process launch". The "--shell" option now can take an optional argument which is the path to the shell to use (or a partial name like "sh" which we will find using the current PATH environment variable). Modified the Process::Attach to use the new ProcessAttachInfo as the sole argument and centralized a lot of code that was in the "process attach" Execute function so that everyone can take advantage of the powerful new attach functionality. llvm-svn: 144615
2011-11-15 11:53:30 +08:00
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;
Added a new class to Process.h: ProcessAttachInfo. This class contains enough info for us to attach by pid, or by name and will also allow us to eventually do a lot more powerful attaches. If you look at the options for the "platform process list" command, there are many options which we should be able to specify. This will allow us to do things like "attach to a process named 'tcsh' that has a parent process ID of 123", or "attach to a process named 'x' which has an effective user ID of 345". I finished up the --shell implementation so that it can be used without the --tty option in "process launch". The "--shell" option now can take an optional argument which is the path to the shell to use (or a partial name like "sh" which we will find using the current PATH environment variable). Modified the Process::Attach to use the new ProcessAttachInfo as the sole argument and centralized a lot of code that was in the "process attach" Execute function so that everyone can take advantage of the powerful new attach functionality. llvm-svn: 144615
2011-11-15 11:53:30 +08:00
if (attach_pid == LLDB_INVALID_PROCESS_ID)
Change Target & Process so they can really be initialized with an invalid architecture. Arrange that this then gets properly set on attach, or when a "file" is set. Add a completer for "process attach -n". Caveats: there isn't currently a way to handle multiple processes with the same name. That will have to wait on a way to pass annotations along with the completion strings. llvm-svn: 110624
2010-08-10 07:31:02 +08:00
{
Added a new class to Process.h: ProcessAttachInfo. This class contains enough info for us to attach by pid, or by name and will also allow us to eventually do a lot more powerful attaches. If you look at the options for the "platform process list" command, there are many options which we should be able to specify. This will allow us to do things like "attach to a process named 'tcsh' that has a parent process ID of 123", or "attach to a process named 'x' which has an effective user ID of 345". I finished up the --shell implementation so that it can be used without the --tty option in "process launch". The "--shell" option now can take an optional argument which is the path to the shell to use (or a partial name like "sh" which we will find using the current PATH environment variable). Modified the Process::Attach to use the new ProcessAttachInfo as the sole argument and centralized a lot of code that was in the "process attach" Execute function so that everyone can take advantage of the powerful new attach functionality. llvm-svn: 144615
2011-11-15 11:53:30 +08:00
char process_name[PATH_MAX];
Take out all the separate places in Attach where we were getting the target architecture, and move that but of functionality into CompleteAttach. llvm-svn: 139766
2011-09-15 09:10:17 +08:00
Added a new class to Process.h: ProcessAttachInfo. This class contains enough info for us to attach by pid, or by name and will also allow us to eventually do a lot more powerful attaches. If you look at the options for the "platform process list" command, there are many options which we should be able to specify. This will allow us to do things like "attach to a process named 'tcsh' that has a parent process ID of 123", or "attach to a process named 'x' which has an effective user ID of 345". I finished up the --shell implementation so that it can be used without the --tty option in "process launch". The "--shell" option now can take an optional argument which is the path to the shell to use (or a partial name like "sh" which we will find using the current PATH environment variable). Modified the Process::Attach to use the new ProcessAttachInfo as the sole argument and centralized a lot of code that was in the "process attach" Execute function so that everyone can take advantage of the powerful new attach functionality. llvm-svn: 144615
2011-11-15 11:53:30 +08:00
if (attach_info.GetExecutableFile().GetPath (process_name, sizeof(process_name)))
Don't try to get the architecture up front when doing attach -w. llvm-svn: 111302
2010-08-18 05:54:19 +08:00
{
Added a new class to Process.h: ProcessAttachInfo. This class contains enough info for us to attach by pid, or by name and will also allow us to eventually do a lot more powerful attaches. If you look at the options for the "platform process list" command, there are many options which we should be able to specify. This will allow us to do things like "attach to a process named 'tcsh' that has a parent process ID of 123", or "attach to a process named 'x' which has an effective user ID of 345". I finished up the --shell implementation so that it can be used without the --tty option in "process launch". The "--shell" option now can take an optional argument which is the path to the shell to use (or a partial name like "sh" which we will find using the current PATH environment variable). Modified the Process::Attach to use the new ProcessAttachInfo as the sole argument and centralized a lot of code that was in the "process attach" Execute function so that everyone can take advantage of the powerful new attach functionality. llvm-svn: 144615
2011-11-15 11:53:30 +08:00
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
{
Added a new class to Process.h: ProcessAttachInfo. This class contains enough info for us to attach by pid, or by name and will also allow us to eventually do a lot more powerful attaches. If you look at the options for the "platform process list" command, there are many options which we should be able to specify. This will allow us to do things like "attach to a process named 'tcsh' that has a parent process ID of 123", or "attach to a process named 'x' which has an effective user ID of 345". I finished up the --shell implementation so that it can be used without the --tty option in "process launch". The "--shell" option now can take an optional argument which is the path to the shell to use (or a partial name like "sh" which we will find using the current PATH environment variable). Modified the Process::Attach to use the new ProcessAttachInfo as the sole argument and centralized a lot of code that was in the "process attach" Execute function so that everyone can take advantage of the powerful new attach functionality. llvm-svn: 144615
2011-11-15 11:53:30 +08:00
error = WillAttachToProcessWithName(process_name, wait_for_launch);
if (error.Success())
{
Modified patch from Matt Kopec that makes sure the run lock is acquired when attaching and makes sure the pid is being set on linux in the process info. llvm-svn: 165804
2012-10-13 00:10:12 +08:00
if (m_run_lock.WriteTryLock())
{
m_should_detach = true;
SetPublicState (eStateAttaching);
// Now attach using these arguments.
error = DoAttachToProcessWithName (process_name, wait_for_launch, attach_info);
}
else
{
// This shouldn't happen
error.SetErrorString("failed to acquire process run lock");
}
Fixed the issue that was causing our monitor process threads to crash, it turned out to be unitialized data in the ProcessLaunchInfo default constructor. Turning on MallocScribble in the environment helped track this down. When we launch and attach using the host layer, we now inform the process that it shouldn't detach when by calling an accessor. llvm-svn: 144882
2011-11-17 12:46:02 +08:00
Added a new class to Process.h: ProcessAttachInfo. This class contains enough info for us to attach by pid, or by name and will also allow us to eventually do a lot more powerful attaches. If you look at the options for the "platform process list" command, there are many options which we should be able to specify. This will allow us to do things like "attach to a process named 'tcsh' that has a parent process ID of 123", or "attach to a process named 'x' which has an effective user ID of 345". I finished up the --shell implementation so that it can be used without the --tty option in "process launch". The "--shell" option now can take an optional argument which is the path to the shell to use (or a partial name like "sh" which we will find using the current PATH environment variable). Modified the Process::Attach to use the new ProcessAttachInfo as the sole argument and centralized a lot of code that was in the "process attach" Execute function so that everyone can take advantage of the powerful new attach functionality. llvm-svn: 144615
2011-11-15 11:53:30 +08:00
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
}
Added a new class to Process.h: ProcessAttachInfo. This class contains enough info for us to attach by pid, or by name and will also allow us to eventually do a lot more powerful attaches. If you look at the options for the "platform process list" command, there are many options which we should be able to specify. This will allow us to do things like "attach to a process named 'tcsh' that has a parent process ID of 123", or "attach to a process named 'x' which has an effective user ID of 345". I finished up the --shell implementation so that it can be used without the --tty option in "process launch". The "--shell" option now can take an optional argument which is the path to the shell to use (or a partial name like "sh" which we will find using the current PATH environment variable). Modified the Process::Attach to use the new ProcessAttachInfo as the sole argument and centralized a lot of code that was in the "process attach" Execute function so that everyone can take advantage of the powerful new attach functionality. llvm-svn: 144615
2011-11-15 11:53:30 +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
{
Added a new class to Process.h: ProcessAttachInfo. This class contains enough info for us to attach by pid, or by name and will also allow us to eventually do a lot more powerful attaches. If you look at the options for the "platform process list" command, there are many options which we should be able to specify. This will allow us to do things like "attach to a process named 'tcsh' that has a parent process ID of 123", or "attach to a process named 'x' which has an effective user ID of 345". I finished up the --shell implementation so that it can be used without the --tty option in "process launch". The "--shell" option now can take an optional argument which is the path to the shell to use (or a partial name like "sh" which we will find using the current PATH environment variable). Modified the Process::Attach to use the new ProcessAttachInfo as the sole argument and centralized a lot of code that was in the "process attach" Execute function so that everyone can take advantage of the powerful new attach functionality. llvm-svn: 144615
2011-11-15 11:53:30 +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
Added a new class to Process.h: ProcessAttachInfo. This class contains enough info for us to attach by pid, or by name and will also allow us to eventually do a lot more powerful attaches. If you look at the options for the "platform process list" command, there are many options which we should be able to specify. This will allow us to do things like "attach to a process named 'tcsh' that has a parent process ID of 123", or "attach to a process named 'x' which has an effective user ID of 345". I finished up the --shell implementation so that it can be used without the --tty option in "process launch". The "--shell" option now can take an optional argument which is the path to the shell to use (or a partial name like "sh" which we will find using the current PATH environment variable). Modified the Process::Attach to use the new ProcessAttachInfo as the sole argument and centralized a lot of code that was in the "process attach" Execute function so that everyone can take advantage of the powerful new attach functionality. llvm-svn: 144615
2011-11-15 11:53:30 +08:00
{
error.SetErrorString ("invalid process name");
Don't try to get the architecture up front when doing attach -w. llvm-svn: 111302
2010-08-18 05:54:19 +08:00
}
Change Target & Process so they can really be initialized with an invalid architecture. Arrange that this then gets properly set on attach, or when a "file" is set. Add a completer for "process attach -n". Caveats: there isn't currently a way to handle multiple processes with the same name. That will have to wait on a way to pass annotations along with the completion strings. llvm-svn: 110624
2010-08-10 07:31:02 +08:00
}
Added a new class to Process.h: ProcessAttachInfo. This class contains enough info for us to attach by pid, or by name and will also allow us to eventually do a lot more powerful attaches. If you look at the options for the "platform process list" command, there are many options which we should be able to specify. This will allow us to do things like "attach to a process named 'tcsh' that has a parent process ID of 123", or "attach to a process named 'x' which has an effective user ID of 345". I finished up the --shell implementation so that it can be used without the --tty option in "process launch". The "--shell" option now can take an optional argument which is the path to the shell to use (or a partial name like "sh" which we will find using the current PATH environment variable). Modified the Process::Attach to use the new ProcessAttachInfo as the sole argument and centralized a lot of code that was in the "process attach" Execute function so that everyone can take advantage of the powerful new attach functionality. llvm-svn: 144615
2011-11-15 11:53:30 +08:00
if (attach_pid != LLDB_INVALID_PROCESS_ID)
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
{
Added a new class to Process.h: ProcessAttachInfo. This class contains enough info for us to attach by pid, or by name and will also allow us to eventually do a lot more powerful attaches. If you look at the options for the "platform process list" command, there are many options which we should be able to specify. This will allow us to do things like "attach to a process named 'tcsh' that has a parent process ID of 123", or "attach to a process named 'x' which has an effective user ID of 345". I finished up the --shell implementation so that it can be used without the --tty option in "process launch". The "--shell" option now can take an optional argument which is the path to the shell to use (or a partial name like "sh" which we will find using the current PATH environment variable). Modified the Process::Attach to use the new ProcessAttachInfo as the sole argument and centralized a lot of code that was in the "process attach" Execute function so that everyone can take advantage of the powerful new attach functionality. llvm-svn: 144615
2011-11-15 11:53:30 +08:00
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())
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
{
Added a new class to Process.h: ProcessAttachInfo. This class contains enough info for us to attach by pid, or by name and will also allow us to eventually do a lot more powerful attaches. If you look at the options for the "platform process list" command, there are many options which we should be able to specify. This will allow us to do things like "attach to a process named 'tcsh' that has a parent process ID of 123", or "attach to a process named 'x' which has an effective user ID of 345". I finished up the --shell implementation so that it can be used without the --tty option in "process launch". The "--shell" option now can take an optional argument which is the path to the shell to use (or a partial name like "sh" which we will find using the current PATH environment variable). Modified the Process::Attach to use the new ProcessAttachInfo as the sole argument and centralized a lot of code that was in the "process attach" Execute function so that everyone can take advantage of the powerful new attach functionality. llvm-svn: 144615
2011-11-15 11:53:30 +08:00
Modified patch from Matt Kopec that makes sure the run lock is acquired when attaching and makes sure the pid is being set on linux in the process info. llvm-svn: 165804
2012-10-13 00:10:12 +08:00
if (m_run_lock.WriteTryLock())
{
// Now attach using these arguments.
m_should_detach = true;
SetPublicState (eStateAttaching);
error = DoAttachToProcessWithID (attach_pid, attach_info);
}
else
{
// This shouldn't happen
error.SetErrorString("failed to acquire process run lock");
}
Added a new class to Process.h: ProcessAttachInfo. This class contains enough info for us to attach by pid, or by name and will also allow us to eventually do a lot more powerful attaches. If you look at the options for the "platform process list" command, there are many options which we should be able to specify. This will allow us to do things like "attach to a process named 'tcsh' that has a parent process ID of 123", or "attach to a process named 'x' which has an effective user ID of 345". I finished up the --shell implementation so that it can be used without the --tty option in "process launch". The "--shell" option now can take an optional argument which is the path to the shell to use (or a partial name like "sh" which we will find using the current PATH environment variable). Modified the Process::Attach to use the new ProcessAttachInfo as the sole argument and centralized a lot of code that was in the "process attach" Execute function so that everyone can take advantage of the powerful new attach functionality. llvm-svn: 144615
2011-11-15 11:53:30 +08:00
if (error.Success())
{
SetNextEventAction(new Process::AttachCompletionHandler(this, attach_info.GetResumeCount()));
StartPrivateStateThread();
}
else
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
{
LLDB now has "Platform" plug-ins. Platform plug-ins are plug-ins that provide an interface to a local or remote debugging platform. By default each host OS that supports LLDB should be registering a "default" platform that will be used unless a new platform is selected. Platforms are responsible for things such as: - getting process information by name or by processs ID - finding platform files. This is useful for remote debugging where there is an SDK with files that might already or need to be cached for debug access. - getting a list of platform supported architectures in the exact order they should be selected. This helps the native x86 platform on MacOSX select the correct x86_64/i386 slice from universal binaries. - Connect to remote platforms for remote debugging - Resolving an executable including finding an executable inside platform specific bundles (macosx uses .app bundles that contain files) and also selecting the appropriate slice of universal files for a given platform. So by default there is always a local platform, but remote platforms can be connected to. I will soon be adding a new "platform" command that will support the following commands: (lldb) platform connect --name machine1 macosx connect://host:port Connected to "machine1" platform. (lldb) platform disconnect macosx This allows LLDB to be well setup to do remote debugging and also once connected process listing and finding for things like: (lldb) process attach --name x<TAB> The currently selected platform plug-in can now auto complete any available processes that start with "x". The responsibilities for the platform plug-in will soon grow and expand. llvm-svn: 127286
2011-03-09 06:40:15 +08:00
if (GetID() != LLDB_INVALID_PROCESS_ID)
{
SetID (LLDB_INVALID_PROCESS_ID);
const char *error_string = error.AsCString();
if (error_string == NULL)
error_string = "attach failed";
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
LLDB now has "Platform" plug-ins. Platform plug-ins are plug-ins that provide an interface to a local or remote debugging platform. By default each host OS that supports LLDB should be registering a "default" platform that will be used unless a new platform is selected. Platforms are responsible for things such as: - getting process information by name or by processs ID - finding platform files. This is useful for remote debugging where there is an SDK with files that might already or need to be cached for debug access. - getting a list of platform supported architectures in the exact order they should be selected. This helps the native x86 platform on MacOSX select the correct x86_64/i386 slice from universal binaries. - Connect to remote platforms for remote debugging - Resolving an executable including finding an executable inside platform specific bundles (macosx uses .app bundles that contain files) and also selecting the appropriate slice of universal files for a given platform. So by default there is always a local platform, but remote platforms can be connected to. I will soon be adding a new "platform" command that will support the following commands: (lldb) platform connect --name machine1 macosx connect://host:port Connected to "machine1" platform. (lldb) platform disconnect macosx This allows LLDB to be well setup to do remote debugging and also once connected process listing and finding for things like: (lldb) process attach --name x<TAB> The currently selected platform plug-in can now auto complete any available processes that start with "x". The responsibilities for the platform plug-in will soon grow and expand. llvm-svn: 127286
2011-03-09 06:40:15 +08:00
SetExitStatus(-1, error_string);
}
}
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
}
return error;
}
The DynamicLoader plug-in instance now lives up in lldb_private::Process where it should live and the lldb_private::Process takes care of managing the auto pointer to the dynamic loader instance. Also, now that the ArchSpec contains the target triple, we are able to correctly set the Target architecture in DidLaunch/DidAttach in the subclasses, and then the lldb_private::Process will find the dynamic loader plug-in by letting the dynamic loader plug-ins inspect the arch/triple in the target. So now the ProcessGDBRemote plug-in is another step closer to be purely process/platform agnostic. I updated the ProcessMacOSX and the ProcessLinux plug-ins accordingly. llvm-svn: 125650
2011-02-16 12:46:07 +08:00
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();
Take out all the separate places in Attach where we were getting the target architecture, and move that but of functionality into CompleteAttach. llvm-svn: 139766
2011-09-15 09:10:17 +08:00
// 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)
{
<rdar://problem/11358639> Switch over to the "*-apple-macosx" for desktop and "*-apple-ios" for iOS triples. Also make the selection process for auto selecting platforms based off of an arch much better. llvm-svn: 156354
2012-05-08 09:45:38 +08:00
const ArchSpec &target_arch = m_target.GetArchitecture();
<rdar://problem/12990038> Fixed an issue where the platform auto select code was changing the architecture and causing the wrong architecture to be assigned to the target. llvm-svn: 172251
2013-01-12 04:49:54 +08:00
if (target_arch.IsValid() && !platform_sp->IsCompatibleArchitecture (target_arch, false, NULL))
<rdar://problem/11358639> Switch over to the "*-apple-macosx" for desktop and "*-apple-ios" for iOS triples. Also make the selection process for auto selecting platforms based off of an arch much better. llvm-svn: 156354
2012-05-08 09:45:38 +08:00
{
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();
Removed the == and != operators from ArchSpec, since equality can be strict or loose and we want code to explicitly choose one or the other. Also renamed the Compare function to IsEqualTo, to avoid confusion. <rdar://problem/12856749> llvm-svn: 170152
2012-12-14 06:07:14 +08:00
if (process_arch.IsValid() && !m_target.GetArchitecture().IsExactMatch(process_arch))
<rdar://problem/11358639> Switch over to the "*-apple-macosx" for desktop and "*-apple-ios" for iOS triples. Also make the selection process for auto selecting platforms based off of an arch much better. llvm-svn: 156354
2012-05-08 09:45:38 +08:00
m_target.SetArchitecture (process_arch);
}
Take out all the separate places in Attach where we were getting the target architecture, and move that but of functionality into CompleteAttach. llvm-svn: 139766
2011-09-15 09:10:17 +08:00
}
// We have completed the attach, now it is time to find the dynamic loader
The DynamicLoader plug-in instance now lives up in lldb_private::Process where it should live and the lldb_private::Process takes care of managing the auto pointer to the dynamic loader instance. Also, now that the ArchSpec contains the target triple, we are able to correctly set the Target architecture in DidLaunch/DidAttach in the subclasses, and then the lldb_private::Process will find the dynamic loader plug-in by letting the dynamic loader plug-ins inspect the arch/triple in the target. So now the ProcessGDBRemote plug-in is another step closer to be purely process/platform agnostic. I updated the ProcessMacOSX and the ProcessLinux plug-ins accordingly. llvm-svn: 125650
2011-02-16 12:46:07 +08:00
// plug-in
Full core file support has been added for mach-o core files. Tracking modules down when you have a UUID and a path has been improved. DynamicLoaderDarwinKernel no longer parses mach-o load commands and it now uses the memory based modules now that we can load modules from memory. Added a target setting named "target.exec-search-paths" which can be used to supply a list of directories to use when trying to look for executables. This allows one or more directories to be used when searching for modules that may not exist in the SDK/PDK. The target automatically adds the directory for the main executable to this list so this should help us in tracking down shared libraries and other binaries. llvm-svn: 150426
2012-02-14 07:10:39 +08:00
DynamicLoader *dyld = GetDynamicLoader ();
if (dyld)
dyld->DidAttach();
The DynamicLoader plug-in instance now lives up in lldb_private::Process where it should live and the lldb_private::Process takes care of managing the auto pointer to the dynamic loader instance. Also, now that the ArchSpec contains the target triple, we are able to correctly set the Target architecture in DidLaunch/DidAttach in the subclasses, and then the lldb_private::Process will find the dynamic loader plug-in by letting the dynamic loader plug-ins inspect the arch/triple in the target. So now the ProcessGDBRemote plug-in is another step closer to be purely process/platform agnostic. I updated the ProcessMacOSX and the ProcessLinux plug-ins accordingly. llvm-svn: 125650
2011-02-16 12:46:07 +08:00
Added a new plug-in type: lldb_private::OperatingSystem. The operating system plug-ins are add on plug-ins for the lldb_private::Process class that can add thread contexts that are read from memory. It is common in kernels to have a lot of threads that are not currently executing on any cores (JTAG debugging also follows this sort of thing) and are context switched out whose state is stored in memory data structures. Clients can now subclass the OperatingSystem plug-ins and then make sure their Create functions correcltly only enable themselves when the right binary/target triple are being debugged. The operating system plug-ins get a chance to attach themselves to processes just after launching or attaching and are given a lldb_private::Process object pointer which can be inspected to see if the main executable, target triple, or any shared libraries match a case where the OS plug-in should be used. Currently the OS plug-ins can create new threads, define the register contexts for these threads (which can all be different if desired), and populate and manage the thread info (stop reason, registers in the register context) as the debug session goes on. llvm-svn: 138228
2011-08-22 10:49:39 +08:00
m_os_ap.reset (OperatingSystem::FindPlugin (this, NULL));
The DynamicLoader plug-in instance now lives up in lldb_private::Process where it should live and the lldb_private::Process takes care of managing the auto pointer to the dynamic loader instance. Also, now that the ArchSpec contains the target triple, we are able to correctly set the Target architecture in DidLaunch/DidAttach in the subclasses, and then the lldb_private::Process will find the dynamic loader plug-in by letting the dynamic loader plug-ins inspect the arch/triple in the target. So now the ProcessGDBRemote plug-in is another step closer to be purely process/platform agnostic. I updated the ProcessMacOSX and the ProcessLinux plug-ins accordingly. llvm-svn: 125650
2011-02-16 12:46:07 +08:00
// Figure out which one is the executable, and set that in our target:
<rdar://problem/12586350> This commit does three things: (a) introduces a new notification model for adding/removing/changing modules to a ModuleList, and applies it to the Target's ModuleList, so that we make sure to always trigger the right set of actions whenever modules come and go in a target. Certain spots in the code still need to "manually" notify the Target for several reasons, so this is a work in progress (b) adds a new capability to the Platforms: locating a scripting resources associated to a module. A scripting resource is a Python file that can load commands, formatters, ... and any other action of interest corresponding to the loading of a module. At the moment, this is only implemented on Mac OS X and only for files inside .dSYM bundles - the next step is going to be letting the frameworks themselves hold their scripting resources. Implementors of platforms for other systems are free to implement "the right thing" for their own worlds (c) hooking up items (a) and (b) so that targets auto-load the scripting resources as the corresponding modules get loaded in a target. This has a few caveats at the moment: - the user needs to manually add the .py file to the dSYM (soon, it will also work in the framework itself) - if two modules with the same name show up during the lifetime of an LLDB session, the second one won't be able to load its scripting resource, but will otherwise work just fine llvm-svn: 167569
2012-11-08 10:22:02 +08:00
const ModuleList &target_modules = m_target.GetImages();
We were accessing the ModuleList in the target without locking it for tasks like setting breakpoints. That's dangerous, since while we are setting a breakpoint, the target might hit the dyld load notification, and start removing modules from the list. This change adds a GetMutex accessor to the ModuleList class, and uses it whenever we are accessing the target's ModuleList (as returned by GetImages().) <rdar://problem/11552372> llvm-svn: 157668
2012-05-30 10:19:25 +08:00
Mutex::Locker modules_locker(target_modules.GetMutex());
size_t num_modules = target_modules.GetSize();
ModuleSP new_executable_module_sp;
The DynamicLoader plug-in instance now lives up in lldb_private::Process where it should live and the lldb_private::Process takes care of managing the auto pointer to the dynamic loader instance. Also, now that the ArchSpec contains the target triple, we are able to correctly set the Target architecture in DidLaunch/DidAttach in the subclasses, and then the lldb_private::Process will find the dynamic loader plug-in by letting the dynamic loader plug-ins inspect the arch/triple in the target. So now the ProcessGDBRemote plug-in is another step closer to be purely process/platform agnostic. I updated the ProcessMacOSX and the ProcessLinux plug-ins accordingly. llvm-svn: 125650
2011-02-16 12:46:07 +08:00
for (int i = 0; i < num_modules; i++)
{
We were accessing the ModuleList in the target without locking it for tasks like setting breakpoints. That's dangerous, since while we are setting a breakpoint, the target might hit the dyld load notification, and start removing modules from the list. This change adds a GetMutex accessor to the ModuleList class, and uses it whenever we are accessing the target's ModuleList (as returned by GetImages().) <rdar://problem/11552372> llvm-svn: 157668
2012-05-30 10:19:25 +08:00
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())
The DynamicLoader plug-in instance now lives up in lldb_private::Process where it should live and the lldb_private::Process takes care of managing the auto pointer to the dynamic loader instance. Also, now that the ArchSpec contains the target triple, we are able to correctly set the Target architecture in DidLaunch/DidAttach in the subclasses, and then the lldb_private::Process will find the dynamic loader plug-in by letting the dynamic loader plug-ins inspect the arch/triple in the target. So now the ProcessGDBRemote plug-in is another step closer to be purely process/platform agnostic. I updated the ProcessMacOSX and the ProcessLinux plug-ins accordingly. llvm-svn: 125650
2011-02-16 12:46:07 +08:00
{
Added the ability to remove orphaned module shared pointers from a ModuleList. This is helping us track down some extra references to ModuleSP objects that are causing things to get kept around for too long. Added a module pointer accessor to target and change a lot of code to use it where it would be more efficient. "taret delete" can now specify "--clean=1" which will cleanup the global module list for any orphaned module in the shared module cache which can save memory and also help track down module reference leaks like we have now. llvm-svn: 137294
2011-08-11 10:48:45 +08:00
if (m_target.GetExecutableModulePointer() != module_sp.get())
We were accessing the ModuleList in the target without locking it for tasks like setting breakpoints. That's dangerous, since while we are setting a breakpoint, the target might hit the dyld load notification, and start removing modules from the list. This change adds a GetMutex accessor to the ModuleList class, and uses it whenever we are accessing the target's ModuleList (as returned by GetImages().) <rdar://problem/11552372> llvm-svn: 157668
2012-05-30 10:19:25 +08:00
new_executable_module_sp = module_sp;
The DynamicLoader plug-in instance now lives up in lldb_private::Process where it should live and the lldb_private::Process takes care of managing the auto pointer to the dynamic loader instance. Also, now that the ArchSpec contains the target triple, we are able to correctly set the Target architecture in DidLaunch/DidAttach in the subclasses, and then the lldb_private::Process will find the dynamic loader plug-in by letting the dynamic loader plug-ins inspect the arch/triple in the target. So now the ProcessGDBRemote plug-in is another step closer to be purely process/platform agnostic. I updated the ProcessMacOSX and the ProcessLinux plug-ins accordingly. llvm-svn: 125650
2011-02-16 12:46:07 +08:00
break;
}
}
We were accessing the ModuleList in the target without locking it for tasks like setting breakpoints. That's dangerous, since while we are setting a breakpoint, the target might hit the dyld load notification, and start removing modules from the list. This change adds a GetMutex accessor to the ModuleList class, and uses it whenever we are accessing the target's ModuleList (as returned by GetImages().) <rdar://problem/11552372> llvm-svn: 157668
2012-05-30 10:19:25 +08:00
if (new_executable_module_sp)
m_target.SetExecutableModule (new_executable_module_sp, false);
The DynamicLoader plug-in instance now lives up in lldb_private::Process where it should live and the lldb_private::Process takes care of managing the auto pointer to the dynamic loader instance. Also, now that the ArchSpec contains the target triple, we are able to correctly set the Target architecture in DidLaunch/DidAttach in the subclasses, and then the lldb_private::Process will find the dynamic loader plug-in by letting the dynamic loader plug-ins inspect the arch/triple in the target. So now the ProcessGDBRemote plug-in is another step closer to be purely process/platform agnostic. I updated the ProcessMacOSX and the ProcessLinux plug-ins accordingly. llvm-svn: 125650
2011-02-16 12:46:07 +08:00
}
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
Add support for debugging KASLR kernels via kdp (the kernel being loaded at a random offset). To get the kernel's UUID and load address I need to send a kdp packet so I had to implement the kernel relocation (and attempt to find the kernel if none was provided to lldb already) in ProcessKDP -- but this code really properly belongs in DynamicLoaderDarwinKernel. I also had to add an optional Stream to ConnectRemote so ProcessKDP::DoConnectRemote can print feedback about the remote kernel's UUID, load address, and notify the user if we auto-loaded the kernel via the UUID. <rdar://problem/7714201> llvm-svn: 164881
2012-09-29 12:02:01 +08:00
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.
Add support for debugging KASLR kernels via kdp (the kernel being loaded at a random offset). To get the kernel's UUID and load address I need to send a kdp packet so I had to implement the kernel relocation (and attempt to find the kernel if none was provided to lldb already) in ProcessKDP -- but this code really properly belongs in DynamicLoaderDarwinKernel. I also had to add an optional Stream to ConnectRemote so ProcessKDP::DoConnectRemote can print feedback about the remote kernel's UUID, load address, and notify the user if we auto-loaded the kernel via the UUID. <rdar://problem/7714201> llvm-svn: 164881
2012-09-29 12:02:01 +08:00
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())
{
Fixed CommandReturnObject::SetImmediateErrorFile() to set the correct stream. Modifed lldb_private::Process to be able to handle connecting to a remote target that isn't running a process. This leaves lldb_private::Process in the eStateConnected state from which we can then do an attach or launch. Modified ProcessGDBRemote to be able to set stdin, stdout, stderr, working dir, disable ASLR and a few other settings down by using new GDB remote packets. This allows us to keep all of our current launch flags and settings intact and still be able to communicate them over to the remote GDB server. Previously these were being sent as arguments to the debugserver binary that we were spawning. Also modified ProcessGDBRemote to handle losing connection to the remote GDB server and always exit immediately. We do this by watching the lldb_private::Communication event bit for the read thread exiting in the ProcessGDBRemote async thread. Added support for many of the new 'Q' packets for setting stdin, stdout, stderr, working dir and disable ASLR to the GDBRemoteCommunication class for easy accesss. Modified debugserver for all of the new 'Q' packets and also made it so that debugserver always exists if it loses connection with the remote debugger. llvm-svn: 126444
2011-02-25 06:24:29 +08:00
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);
}
Fixed CommandReturnObject::SetImmediateErrorFile() to set the correct stream. Modifed lldb_private::Process to be able to handle connecting to a remote target that isn't running a process. This leaves lldb_private::Process in the eStateConnected state from which we can then do an attach or launch. Modified ProcessGDBRemote to be able to set stdin, stdout, stderr, working dir, disable ASLR and a few other settings down by using new GDB remote packets. This allows us to keep all of our current launch flags and settings intact and still be able to communicate them over to the remote GDB server. Previously these were being sent as arguments to the debugserver binary that we were spawning. Also modified ProcessGDBRemote to handle losing connection to the remote GDB server and always exit immediately. We do this by watching the lldb_private::Communication event bit for the read thread exiting in the ProcessGDBRemote async thread. Added support for many of the new 'Q' packets for setting stdin, stdout, stderr, working dir and disable ASLR to the GDBRemoteCommunication class for easy accesss. Modified debugserver for all of the new 'Q' packets and also made it so that debugserver always exists if it loses connection with the remote debugger. llvm-svn: 126444
2011-02-25 06:24:29 +08:00
}
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;
}
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
Error
Switch to setting the write side of the run lock when we call Resume. Then make a PrivateResume that doesn't switch the run-lock state, and use that where we are resuming without changing the public resume state. llvm-svn: 155092
2012-04-19 09:40:33 +08:00
Process::PrivateResume ()
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
{
<rdar://problem/13521159> LLDB is crashing when logging is enabled from lldb-perf-clang. This has to do with the global destructor chain as the process and its threads are being torn down. All logging channels now make one and only one instance that is kept in a global pointer which is never freed. This guarantees that logging can correctly continue as the process tears itself down. llvm-svn: 178191
2013-03-28 07:08:40 +08:00
Log *log(lldb_private::GetLogIfAnyCategoriesSet (LIBLLDB_LOG_PROCESS|LIBLLDB_LOG_STEP));
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
if (log)
Reworked the way Process::RunThreadPlan and the ThreadPlanCallFunction interoperate to fix problems where hitting auto-continue signals while running a thread plan would cause us to lose control of the debug session. <rdar://problem/12993641> llvm-svn: 174793
2013-02-09 09:29:05 +08:00
log->Printf("Process::PrivateResume() m_stop_id = %u, public state: %s private state: %s",
Move the handling of breakpoint conditions from the Private event loop to the StopInfoBreakpoint::DoActions, which happens as the event is removed. Also use the return value of asynchronous breakpoint callbacks, they get checked before, and override the breakpoint conditions. Added ProcessModInfo class, to unify "stop_id generation" and "memory modification generation", and use where needed. llvm-svn: 137102
2011-08-09 10:12:22 +08:00
m_mod_id.GetStopID(),
More useful STEP logging. Be sure to clear out the base plan's m_report_run and m_report_stop each time we resume so we don't use stale values. llvm-svn: 124113
2011-01-24 14:34:17 +08:00
StateAsCString(m_public_state.GetValue()),
StateAsCString(m_private_state.GetValue()));
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
Error error (WillResume());
// Tell the process it is about to resume before the thread list
if (error.Success())
{
Fixed a typo in comment. llvm-svn: 120733
2010-12-03 04:53:05 +08:00
// Now let the thread list know we are about to resume so it
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
// 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()
// to see if they are suppoed to start back up with a signal.
if (m_thread_list.WillResume())
{
We sometimes need to be able to call functions (via Process::RunThreadPlan) from code run on the private state thread. To do that we have to spin up a temporary "private state thread" that will respond to events from the lower level process plugins. This check-in should work to do that, but it is still buggy. However, if you don't call functions on the private state thread, these changes make no difference. This patch also moves the code in the AppleObjCRuntime step-through-trampoline handler that might call functions (in the case where the debug server doesn't support the memory allocate/deallocate packet) out to a safe place to do that call. llvm-svn: 154230
2012-04-07 08:00:41 +08:00
// Last thing, do the PreResumeActions.
if (!RunPreResumeActions())
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
{
Reworked the way Process::RunThreadPlan and the ThreadPlanCallFunction interoperate to fix problems where hitting auto-continue signals while running a thread plan would cause us to lose control of the debug session. <rdar://problem/12993641> llvm-svn: 174793
2013-02-09 09:29:05 +08:00
error.SetErrorStringWithFormat ("Process::PrivateResume PreResumeActions failed, not resuming.");
We sometimes need to be able to call functions (via Process::RunThreadPlan) from code run on the private state thread. To do that we have to spin up a temporary "private state thread" that will respond to events from the lower level process plugins. This check-in should work to do that, but it is still buggy. However, if you don't call functions on the private state thread, these changes make no difference. This patch also moves the code in the AppleObjCRuntime step-through-trampoline handler that might call functions (in the case where the debug server doesn't support the memory allocate/deallocate packet) out to a safe place to do that call. llvm-svn: 154230
2012-04-07 08:00:41 +08:00
}
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.");
}
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
}
else
{
Initial check-in of "fancy" inlined stepping. Doesn't do anything useful unless you switch LLDB_FANCY_INLINED_STEPPING to true. With that on, basic inlined stepping works, including step-over of inlined functions. But for some as yet mysterious reason i386 debugging gets an assert and dies immediately. So for now its off. llvm-svn: 163044
2012-09-01 09:02:41 +08:00
// 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);
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
}
More useful STEP logging. Be sure to clear out the base plan's m_report_run and m_report_stop each time we resume so we don't use stale values. llvm-svn: 124113
2011-01-24 14:34:17 +08:00
else if (log)
Reworked the way Process::RunThreadPlan and the ThreadPlanCallFunction interoperate to fix problems where hitting auto-continue signals while running a thread plan would cause us to lose control of the debug session. <rdar://problem/12993641> llvm-svn: 174793
2013-02-09 09:29:05 +08:00
log->Printf ("Process::PrivateResume() got an error \"%s\".", error.AsCString("<unknown error>"));
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
return error;
}
Error
Process::Halt ()
{
Make sure that when if we are going to Halt while the process is in the middle of HandlePrivateEvent we wait till that is done. We need a stronger way to do this, but in practice this works and using some locking strategy is harder because Halt & HandlePrivateEvent generally happen on different threads. llvm-svn: 158042
2012-06-06 08:29:30 +08:00
// 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);
Added a completion action class to the Process events so that we can make things like Attach and later Launch start their job, and then return to the event loop while waiting for the work to be done. llvm-svn: 124520
2011-01-29 09:49:25 +08:00
// Pause our private state thread so we can ensure no one else eats
// the stop event out from under us.
Rework the RunThreadPlan event handling to use Event Hijacking not stopping the event thread. Also clarify the logic of the function. llvm-svn: 125083
2011-02-08 13:20:59 +08:00
Listener halt_listener ("lldb.process.halt_listener");
HijackPrivateProcessEvents(&halt_listener);
Added a completion action class to the Process events so that we can make things like Attach and later Launch start their job, and then return to the event loop while waiting for the work to be done. llvm-svn: 124520
2011-01-29 09:49:25 +08:00
EventSP event_sp;
Finished up the async attach support. This allows us to request to attach by name or by pid (with or without waiting for a process to launch) and catch the response asynchronously. llvm-svn: 124530
2011-01-29 15:10:55 +08:00
Error error (WillHalt());
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
Finished up the async attach support. This allows us to request to attach by name or by pid (with or without waiting for a process to launch) and catch the response asynchronously. llvm-svn: 124530
2011-01-29 15:10:55 +08:00
if (error.Success())
Added a completion action class to the Process events so that we can make things like Attach and later Launch start their job, and then return to the event loop while waiting for the work to be done. llvm-svn: 124520
2011-01-29 09:49:25 +08:00
{
Fixed Process::Halt() as it was broken for "process halt" after recent changes to the DoHalt down in ProcessGDBRemote. I also moved the functionality that was in ProcessGDBRemote::DoHalt up into Process::Halt so not every class has to implement a tricky halt/resume on the internal state thread. The functionality is the same as it was before with two changes: - when we eat the event we now just reuse the event we consume when the private state thread is paused and set the interrupted bool on the event if needed - we also properly update the Process::m_public_state with the state of the event we consume. Prior to this, if you issued a "process halt" it would eat the event, not update the process state, and then produce a new event with the interrupted bit set and send it. Anyone listening to the event would get the stopped event with a process that whose state was set to "running". Fixed debugserver to not have to be spawned with the architecture of the inferior process. This worked fine for launching processes, but when attaching to processes by name or pid without a file in lldb, it would fail. Now debugserver can support multiple architectures for a native debug session on the current host. This currently means i386 and x86_64 are supported in the same binary and a x86_64 debugserver can attach to a i386 executable. This change involved a lot of changes to make sure we dynamically detect the correct registers for the inferior process. llvm-svn: 119680
2010-11-18 13:57:03 +08:00
Finished up the async attach support. This allows us to request to attach by name or by pid (with or without waiting for a process to launch) and catch the response asynchronously. llvm-svn: 124530
2011-01-29 15:10:55 +08:00
bool caused_stop = false;
// Ask the process subclass to actually halt our process
error = DoHalt(caused_stop);
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
if (error.Success())
Added an "Interrupted" bit to the ProcessEventData. Halt now generates an event with the Interrupted bit set. Process::HandlePrivateEvent ignores Interrupted events. DoHalt is changed to ensure that the stop even is processed, and an event with the Interrupted event is posted. Finally ClangFunction is rationalized to use this facility so the that Halt is handled more deterministically. llvm-svn: 119453
2010-11-17 10:32:00 +08:00
{
Finished up the async attach support. This allows us to request to attach by name or by pid (with or without waiting for a process to launch) and catch the response asynchronously. llvm-svn: 124530
2011-01-29 15:10:55 +08:00
if (m_public_state.GetValue() == eStateAttaching)
{
SetExitStatus(SIGKILL, "Cancelled async attach.");
Destroy ();
}
else
Added an "Interrupted" bit to the ProcessEventData. Halt now generates an event with the Interrupted bit set. Process::HandlePrivateEvent ignores Interrupted events. DoHalt is changed to ensure that the stop even is processed, and an event with the Interrupted event is posted. Finally ClangFunction is rationalized to use this facility so the that Halt is handled more deterministically. llvm-svn: 119453
2010-11-17 10:32:00 +08:00
{
Added a completion action class to the Process events so that we can make things like Attach and later Launch start their job, and then return to the event loop while waiting for the work to be done. llvm-svn: 124520
2011-01-29 09:49:25 +08:00
// 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)
Fixed Process::Halt() as it was broken for "process halt" after recent changes to the DoHalt down in ProcessGDBRemote. I also moved the functionality that was in ProcessGDBRemote::DoHalt up into Process::Halt so not every class has to implement a tricky halt/resume on the internal state thread. The functionality is the same as it was before with two changes: - when we eat the event we now just reuse the event we consume when the private state thread is paused and set the interrupted bool on the event if needed - we also properly update the Process::m_public_state with the state of the event we consume. Prior to this, if you issued a "process halt" it would eat the event, not update the process state, and then produce a new event with the interrupted bit set and send it. Anyone listening to the event would get the stopped event with a process that whose state was set to "running". Fixed debugserver to not have to be spawned with the architecture of the inferior process. This worked fine for launching processes, but when attaching to processes by name or pid without a file in lldb, it would fail. Now debugserver can support multiple architectures for a native debug session on the current host. This currently means i386 and x86_64 are supported in the same binary and a x86_64 debugserver can attach to a i386 executable. This change involved a lot of changes to make sure we dynamically detect the correct registers for the inferior process. llvm-svn: 119680
2010-11-18 13:57:03 +08:00
{
Rework the RunThreadPlan event handling to use Event Hijacking not stopping the event thread. Also clarify the logic of the function. llvm-svn: 125083
2011-02-08 13:20:59 +08:00
// Wait for 1 second for the process to stop.
Added a completion action class to the Process events so that we can make things like Attach and later Launch start their job, and then return to the event loop while waiting for the work to be done. llvm-svn: 124520
2011-01-29 09:49:25 +08:00
TimeValue timeout_time;
timeout_time = TimeValue::Now();
timeout_time.OffsetWithSeconds(1);
Rework the RunThreadPlan event handling to use Event Hijacking not stopping the event thread. Also clarify the logic of the function. llvm-svn: 125083
2011-02-08 13:20:59 +08:00
bool got_event = halt_listener.WaitForEvent (&timeout_time, event_sp);
StateType state = ProcessEventData::GetStateFromEvent(event_sp.get());
Added a completion action class to the Process events so that we can make things like Attach and later Launch start their job, and then return to the event loop while waiting for the work to be done. llvm-svn: 124520
2011-01-29 09:49:25 +08:00
Rework the RunThreadPlan event handling to use Event Hijacking not stopping the event thread. Also clarify the logic of the function. llvm-svn: 125083
2011-02-08 13:20:59 +08:00
if (!got_event || state == eStateInvalid)
Fixed Process::Halt() as it was broken for "process halt" after recent changes to the DoHalt down in ProcessGDBRemote. I also moved the functionality that was in ProcessGDBRemote::DoHalt up into Process::Halt so not every class has to implement a tricky halt/resume on the internal state thread. The functionality is the same as it was before with two changes: - when we eat the event we now just reuse the event we consume when the private state thread is paused and set the interrupted bool on the event if needed - we also properly update the Process::m_public_state with the state of the event we consume. Prior to this, if you issued a "process halt" it would eat the event, not update the process state, and then produce a new event with the interrupted bit set and send it. Anyone listening to the event would get the stopped event with a process that whose state was set to "running". Fixed debugserver to not have to be spawned with the architecture of the inferior process. This worked fine for launching processes, but when attaching to processes by name or pid without a file in lldb, it would fail. Now debugserver can support multiple architectures for a native debug session on the current host. This currently means i386 and x86_64 are supported in the same binary and a x86_64 debugserver can attach to a i386 executable. This change involved a lot of changes to make sure we dynamically detect the correct registers for the inferior process. llvm-svn: 119680
2010-11-18 13:57:03 +08:00
{
Added a completion action class to the Process events so that we can make things like Attach and later Launch start their job, and then return to the event loop while waiting for the work to be done. llvm-svn: 124520
2011-01-29 09:49:25 +08:00
// We timeout out and didn't get a stop event...
Rework the RunThreadPlan event handling to use Event Hijacking not stopping the event thread. Also clarify the logic of the function. llvm-svn: 125083
2011-02-08 13:20:59 +08:00
error.SetErrorStringWithFormat ("Halt timed out. State = %s", StateAsCString(GetState()));
Fixed Process::Halt() as it was broken for "process halt" after recent changes to the DoHalt down in ProcessGDBRemote. I also moved the functionality that was in ProcessGDBRemote::DoHalt up into Process::Halt so not every class has to implement a tricky halt/resume on the internal state thread. The functionality is the same as it was before with two changes: - when we eat the event we now just reuse the event we consume when the private state thread is paused and set the interrupted bool on the event if needed - we also properly update the Process::m_public_state with the state of the event we consume. Prior to this, if you issued a "process halt" it would eat the event, not update the process state, and then produce a new event with the interrupted bit set and send it. Anyone listening to the event would get the stopped event with a process that whose state was set to "running". Fixed debugserver to not have to be spawned with the architecture of the inferior process. This worked fine for launching processes, but when attaching to processes by name or pid without a file in lldb, it would fail. Now debugserver can support multiple architectures for a native debug session on the current host. This currently means i386 and x86_64 are supported in the same binary and a x86_64 debugserver can attach to a i386 executable. This change involved a lot of changes to make sure we dynamically detect the correct registers for the inferior process. llvm-svn: 119680
2010-11-18 13:57:03 +08:00
}
else
{
Fixed an issue with the pthread_setspecific() where we weren't NULL-ing out the thread specific data and were destroying the thread specfic data more than once. Also added the ability to ask a lldb::StateType if it is stopped with an additional paramter of "must_exist" which means that the state must be a stopped state for a process that still exists. This means that eStateExited and eStateUnloaded will no longer return true if "must_exist" is set to true. llvm-svn: 144875
2011-11-17 09:23:07 +08:00
if (StateIsStoppedState (state, false))
Added a completion action class to the Process events so that we can make things like Attach and later Launch start their job, and then return to the event loop while waiting for the work to be done. llvm-svn: 124520
2011-01-29 09:49:25 +08:00
{
// 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
{
<rdar://problem/13521159> LLDB is crashing when logging is enabled from lldb-perf-clang. This has to do with the global destructor chain as the process and its threads are being torn down. All logging channels now make one and only one instance that is kept in a global pointer which is never freed. This guarantees that logging can correctly continue as the process tears itself down. llvm-svn: 178191
2013-03-28 07:08:40 +08:00
Log *log(lldb_private::GetLogIfAllCategoriesSet (LIBLLDB_LOG_PROCESS));
Added a completion action class to the Process events so that we can make things like Attach and later Launch start their job, and then return to the event loop while waiting for the work to be done. llvm-svn: 124520
2011-01-29 09:49:25 +08:00
if (log)
log->Printf("Process::Halt() failed to stop, state is: %s", StateAsCString(state));
error.SetErrorString ("Did not get stopped event after halt.");
}
Fixed Process::Halt() as it was broken for "process halt" after recent changes to the DoHalt down in ProcessGDBRemote. I also moved the functionality that was in ProcessGDBRemote::DoHalt up into Process::Halt so not every class has to implement a tricky halt/resume on the internal state thread. The functionality is the same as it was before with two changes: - when we eat the event we now just reuse the event we consume when the private state thread is paused and set the interrupted bool on the event if needed - we also properly update the Process::m_public_state with the state of the event we consume. Prior to this, if you issued a "process halt" it would eat the event, not update the process state, and then produce a new event with the interrupted bit set and send it. Anyone listening to the event would get the stopped event with a process that whose state was set to "running". Fixed debugserver to not have to be spawned with the architecture of the inferior process. This worked fine for launching processes, but when attaching to processes by name or pid without a file in lldb, it would fail. Now debugserver can support multiple architectures for a native debug session on the current host. This currently means i386 and x86_64 are supported in the same binary and a x86_64 debugserver can attach to a i386 executable. This change involved a lot of changes to make sure we dynamically detect the correct registers for the inferior process. llvm-svn: 119680
2010-11-18 13:57:03 +08:00
}
}
Added a completion action class to the Process events so that we can make things like Attach and later Launch start their job, and then return to the event loop while waiting for the work to be done. llvm-svn: 124520
2011-01-29 09:49:25 +08:00
DidHalt();
}
Added an "Interrupted" bit to the ProcessEventData. Halt now generates an event with the Interrupted bit set. Process::HandlePrivateEvent ignores Interrupted events. DoHalt is changed to ensure that the stop even is processed, and an event with the Interrupted event is posted. Finally ClangFunction is rationalized to use this facility so the that Halt is handled more deterministically. llvm-svn: 119453
2010-11-17 10:32:00 +08:00
}
Added a completion action class to the Process events so that we can make things like Attach and later Launch start their job, and then return to the event loop while waiting for the work to be done. llvm-svn: 124520
2011-01-29 09:49:25 +08:00
}
// Resume our private state thread before we post the event (if any)
Rework the RunThreadPlan event handling to use Event Hijacking not stopping the event thread. Also clarify the logic of the function. llvm-svn: 125083
2011-02-08 13:20:59 +08:00
RestorePrivateProcessEvents();
Fixed Process::Halt() as it was broken for "process halt" after recent changes to the DoHalt down in ProcessGDBRemote. I also moved the functionality that was in ProcessGDBRemote::DoHalt up into Process::Halt so not every class has to implement a tricky halt/resume on the internal state thread. The functionality is the same as it was before with two changes: - when we eat the event we now just reuse the event we consume when the private state thread is paused and set the interrupted bool on the event if needed - we also properly update the Process::m_public_state with the state of the event we consume. Prior to this, if you issued a "process halt" it would eat the event, not update the process state, and then produce a new event with the interrupted bit set and send it. Anyone listening to the event would get the stopped event with a process that whose state was set to "running". Fixed debugserver to not have to be spawned with the architecture of the inferior process. This worked fine for launching processes, but when attaching to processes by name or pid without a file in lldb, it would fail. Now debugserver can support multiple architectures for a native debug session on the current host. This currently means i386 and x86_64 are supported in the same binary and a x86_64 debugserver can attach to a i386 executable. This change involved a lot of changes to make sure we dynamically detect the correct registers for the inferior process. llvm-svn: 119680
2010-11-18 13:57:03 +08:00
Added a completion action class to the Process events so that we can make things like Attach and later Launch start their job, and then return to the event loop while waiting for the work to be done. llvm-svn: 124520
2011-01-29 09:49:25 +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);
Fixed Process::Halt() as it was broken for "process halt" after recent changes to the DoHalt down in ProcessGDBRemote. I also moved the functionality that was in ProcessGDBRemote::DoHalt up into Process::Halt so not every class has to implement a tricky halt/resume on the internal state thread. The functionality is the same as it was before with two changes: - when we eat the event we now just reuse the event we consume when the private state thread is paused and set the interrupted bool on the event if needed - we also properly update the Process::m_public_state with the state of the event we consume. Prior to this, if you issued a "process halt" it would eat the event, not update the process state, and then produce a new event with the interrupted bit set and send it. Anyone listening to the event would get the stopped event with a process that whose state was set to "running". Fixed debugserver to not have to be spawned with the architecture of the inferior process. This worked fine for launching processes, but when attaching to processes by name or pid without a file in lldb, it would fail. Now debugserver can support multiple architectures for a native debug session on the current host. This currently means i386 and x86_64 are supported in the same binary and a x86_64 debugserver can attach to a i386 executable. This change involved a lot of changes to make sure we dynamically detect the correct registers for the inferior process. llvm-svn: 119680
2010-11-18 13:57:03 +08:00
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
return error;
}
Rationalize how we do Halt-ing before Destroy and Detach. <rdar://problem/13527167> llvm-svn: 178325
2013-03-29 09:18:12 +08:00
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;
}
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
Error
Process::Detach ()
{
Rationalize how we do Halt-ing before Destroy and Detach. <rdar://problem/13527167> llvm-svn: 178325
2013-03-29 09:18:12 +08:00
EventSP exit_event_sp;
Error error;
m_destroy_in_process = true;
error = WillDetach();
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
if (error.Success())
{
Rationalize how we do Halt-ing before Destroy and Detach. <rdar://problem/13527167> llvm-svn: 178325
2013-03-29 09:18:12 +08:00
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;
}
}
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
error = DoDetach();
if (error.Success())
{
DidDetach();
StopPrivateStateThread();
}
}
Rationalize how we do Halt-ing before Destroy and Detach. <rdar://problem/13527167> llvm-svn: 178325
2013-03-29 09:18:12 +08:00
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.
m_run_lock.WriteUnlock();
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
return error;
}
Error
Process::Destroy ()
{
Move m_destroy_in_process to Process (from ProcessKDP) since it is generally useful, and use it to keep from doing the OS Plugin UpdateThreadList while destroying, since if that does anything that requires the API lock it may deadlock against whoever is running the Process::Destroy. <rdar://problem/13308627> llvm-svn: 176375
2013-03-02 04:04:25 +08:00
// 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;
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
Error error (WillDestroy());
if (error.Success())
{
<rdar://problem/11935492> Fixed an issue where if we call "Process::Destroy()" and the process is running, if we try to stop it and get "exited" back as the stop reason, we will still deliver the exited event. llvm-svn: 163591
2012-09-11 10:33:37 +08:00
EventSP exit_event_sp;
Rationalize how we do Halt-ing before Destroy and Detach. <rdar://problem/13527167> llvm-svn: 178325
2013-03-29 09:18:12 +08:00
if (DestroyRequiresHalt())
Process::Destroy should Halt before it tries to destroy so we don't have race conditions where we are in the middle of trying to service an event when we go to Destroy. The AttachCompletionHandler should note that it has restarted the target if it indeed does so. llvm-svn: 157327
2012-05-23 23:46:31 +08:00
{
Rationalize how we do Halt-ing before Destroy and Detach. <rdar://problem/13527167> llvm-svn: 178325
2013-03-29 09:18:12 +08:00
error = HaltForDestroyOrDetach(exit_event_sp);
Process::Destroy should Halt before it tries to destroy so we don't have race conditions where we are in the middle of trying to service an event when we go to Destroy. The AttachCompletionHandler should note that it has restarted the target if it indeed does so. llvm-svn: 157327
2012-05-23 23:46:31 +08:00
}
Rationalize how we do Halt-ing before Destroy and Detach. <rdar://problem/13527167> llvm-svn: 178325
2013-03-29 09:18:12 +08:00
Make sure that when if we are going to Halt while the process is in the middle of HandlePrivateEvent we wait till that is done. We need a stronger way to do this, but in practice this works and using some locking strategy is harder because Halt & HandlePrivateEvent generally happen on different threads. llvm-svn: 158042
2012-06-06 08:29:30 +08:00
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();
}
Rationalize how we do Halt-ing before Destroy and Detach. <rdar://problem/13527167> llvm-svn: 178325
2013-03-29 09:18:12 +08:00
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
error = DoDestroy();
if (error.Success())
{
DidDestroy();
StopPrivateStateThread();
}
Make processes use InputReaders for their input. Move the process ReadThread stuff into the main Process class (out of the Process Plugins). This has the (intended) side effect of disabling the command line tool from reading input/commands while the process is running (the input is directed to the running process rather than to the command interpreter). llvm-svn: 119329
2010-11-16 13:07:41 +08:00
m_stdio_communication.StopReadThread();
m_stdio_communication.Disconnect();
if (m_process_input_reader && m_process_input_reader->IsActive())
m_target.GetDebugger().PopInputReader (m_process_input_reader);
if (m_process_input_reader)
m_process_input_reader.reset();
<rdar://problem/11935492> Fixed an issue where if we call "Process::Destroy()" and the process is running, if we try to stop it and get "exited" back as the stop reason, we will still deliver the exited event. llvm-svn: 163591
2012-09-11 10:33:37 +08:00
// 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);
}
Make sure that DoResume doesn't stall if we shut down the async thread while DoResume is waiting for packet confirmation. Also added a bit more logging. Also, unlock the writer end of the run lock in Process.cpp on our way out of the private state thread so that the Process can shut down cleanly. <rdar://problem/11228538> llvm-svn: 154601
2012-04-13 02:49:31 +08:00
// 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.
m_run_lock.WriteUnlock();
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
Move m_destroy_in_process to Process (from ProcessKDP) since it is generally useful, and use it to keep from doing the OS Plugin UpdateThreadList while destroying, since if that does anything that requires the API lock it may deadlock against whoever is running the Process::Destroy. <rdar://problem/13308627> llvm-svn: 176375
2013-03-02 04:04:25 +08:00
m_destroy_in_process = false;
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
return error;
}
Error
Process::Signal (int signal)
{
Error error (WillSignal());
if (error.Success())
{
error = DoSignal(signal);
if (error.Success())
DidSignal();
}
return error;
}
Made lldb_private::ArchSpec contain much more than just an architecture. It now, in addition to cpu type/subtype and architecture flavor, contains: - byte order (big endian, little endian) - address size in bytes - llvm::Triple for true target triple support and for more powerful plug-in selection. llvm-svn: 125602
2011-02-16 05:59:32 +08:00
lldb::ByteOrder
Process::GetByteOrder () const
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
{
Made lldb_private::ArchSpec contain much more than just an architecture. It now, in addition to cpu type/subtype and architecture flavor, contains: - byte order (big endian, little endian) - address size in bytes - llvm::Triple for true target triple support and for more powerful plug-in selection. llvm-svn: 125602
2011-02-16 05:59:32 +08:00
return m_target.GetArchitecture().GetByteOrder();
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
uint32_t
Made lldb_private::ArchSpec contain much more than just an architecture. It now, in addition to cpu type/subtype and architecture flavor, contains: - byte order (big endian, little endian) - address size in bytes - llvm::Triple for true target triple support and for more powerful plug-in selection. llvm-svn: 125602
2011-02-16 05:59:32 +08:00
Process::GetAddressByteSize () const
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
{
Made lldb_private::ArchSpec contain much more than just an architecture. It now, in addition to cpu type/subtype and architecture flavor, contains: - byte order (big endian, little endian) - address size in bytes - llvm::Triple for true target triple support and for more powerful plug-in selection. llvm-svn: 125602
2011-02-16 05:59:32 +08:00
return m_target.GetArchitecture().GetAddressByteSize();
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
Made lldb_private::ArchSpec contain much more than just an architecture. It now, in addition to cpu type/subtype and architecture flavor, contains: - byte order (big endian, little endian) - address size in bytes - llvm::Triple for true target triple support and for more powerful plug-in selection. llvm-svn: 125602
2011-02-16 05:59:32 +08:00
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
bool
Process::ShouldBroadcastEvent (Event *event_ptr)
{
const StateType state = Process::ProcessEventData::GetStateFromEvent (event_ptr);
bool return_value = true;
<rdar://problem/13521159> LLDB is crashing when logging is enabled from lldb-perf-clang. This has to do with the global destructor chain as the process and its threads are being torn down. All logging channels now make one and only one instance that is kept in a global pointer which is never freed. This guarantees that logging can correctly continue as the process tears itself down. llvm-svn: 178191
2013-03-28 07:08:40 +08:00
Log *log(lldb_private::GetLogIfAnyCategoriesSet(LIBLLDB_LOG_EVENTS | LIBLLDB_LOG_PROCESS));
Reworked the way Process::RunThreadPlan and the ThreadPlanCallFunction interoperate to fix problems where hitting auto-continue signals while running a thread plan would cause us to lose control of the debug session. <rdar://problem/12993641> llvm-svn: 174793
2013-02-09 09:29:05 +08:00
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
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:
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
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);
Reworked the way Process::RunThreadPlan and the ThreadPlanCallFunction interoperate to fix problems where hitting auto-continue signals while running a thread plan would cause us to lose control of the debug session. <rdar://problem/12993641> llvm-svn: 174793
2013-02-09 09:29:05 +08:00
switch (m_last_broadcast_state)
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
{
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.
Two changes in this checkin. Added a ThreadPlanKind so that I can do some reasoning based on the kind of thread plan without having to use RTTI. Removed the ThreadPlanContinue and replaced with a ShouldAutoContinue query that serves the same purpose. Having to push another plan to assert that if there's no other indication the target should continue when this plan is popped was flakey and error prone. This method is more stable, and fixed problems we were having with thread specific breakpoints. llvm-svn: 106378
2010-06-19 12:45:32 +08:00
// If no thread has an opinion, we don't report it.
Always call RefreshStateAfterStop when we get a stop event. We were skipping doing it in the case where we had interrupted the target. Presumably at some point in the past RefreshStateAfterStop was done more directly when we handled the interrupt, but it isn't any more so now we need to do it all the time. llvm-svn: 156894
2012-05-16 09:32:14 +08:00
RefreshStateAfterStop ();
Added an "Interrupted" bit to the ProcessEventData. Halt now generates an event with the Interrupted bit set. Process::HandlePrivateEvent ignores Interrupted events. DoHalt is changed to ensure that the stop even is processed, and an event with the Interrupted event is posted. Finally ClangFunction is rationalized to use this facility so the that Halt is handled more deterministically. llvm-svn: 119453
2010-11-17 10:32:00 +08:00
if (ProcessEventData::GetInterruptedFromEvent (event_ptr))
{
Fixed Process::Halt() as it was broken for "process halt" after recent changes to the DoHalt down in ProcessGDBRemote. I also moved the functionality that was in ProcessGDBRemote::DoHalt up into Process::Halt so not every class has to implement a tricky halt/resume on the internal state thread. The functionality is the same as it was before with two changes: - when we eat the event we now just reuse the event we consume when the private state thread is paused and set the interrupted bool on the event if needed - we also properly update the Process::m_public_state with the state of the event we consume. Prior to this, if you issued a "process halt" it would eat the event, not update the process state, and then produce a new event with the interrupted bit set and send it. Anyone listening to the event would get the stopped event with a process that whose state was set to "running". Fixed debugserver to not have to be spawned with the architecture of the inferior process. This worked fine for launching processes, but when attaching to processes by name or pid without a file in lldb, it would fail. Now debugserver can support multiple architectures for a native debug session on the current host. This currently means i386 and x86_64 are supported in the same binary and a x86_64 debugserver can attach to a i386 executable. This change involved a lot of changes to make sure we dynamically detect the correct registers for the inferior process. llvm-svn: 119680
2010-11-18 13:57:03 +08:00
if (log)
Reworked the way Process::RunThreadPlan and the ThreadPlanCallFunction interoperate to fix problems where hitting auto-continue signals while running a thread plan would cause us to lose control of the debug session. <rdar://problem/12993641> llvm-svn: 174793
2013-02-09 09:29:05 +08:00
log->Printf ("Process::ShouldBroadcastEvent (%p) stopped due to an interrupt, state: %s",
event_ptr,
StateAsCString(state));
return_value = true;
Added an "Interrupted" bit to the ProcessEventData. Halt now generates an event with the Interrupted bit set. Process::HandlePrivateEvent ignores Interrupted events. DoHalt is changed to ensure that the stop even is processed, and an event with the Interrupted event is posted. Finally ClangFunction is rationalized to use this facility so the that Halt is handled more deterministically. llvm-svn: 119453
2010-11-17 10:32:00 +08:00
}
else
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
{
Reworked the way Process::RunThreadPlan and the ThreadPlanCallFunction interoperate to fix problems where hitting auto-continue signals while running a thread plan would cause us to lose control of the debug session. <rdar://problem/12993641> llvm-svn: 174793
2013-02-09 09:29:05 +08:00
// 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.
bool was_restarted = ProcessEventData::GetRestartedFromEvent (event_ptr);
bool should_resume = false;
if (!was_restarted)
should_resume = m_thread_list.ShouldStop (event_ptr) == false;
if (was_restarted || should_resume)
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
{
Reworked the way Process::RunThreadPlan and the ThreadPlanCallFunction interoperate to fix problems where hitting auto-continue signals while running a thread plan would cause us to lose control of the debug session. <rdar://problem/12993641> llvm-svn: 174793
2013-02-09 09:29:05 +08:00
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)
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
{
case eVoteYes:
Reworked the way Process::RunThreadPlan and the ThreadPlanCallFunction interoperate to fix problems where hitting auto-continue signals while running a thread plan would cause us to lose control of the debug session. <rdar://problem/12993641> llvm-svn: 174793
2013-02-09 09:29:05 +08:00
return_value = true;
break;
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
case eVoteNoOpinion:
case eVoteNo:
return_value = false;
break;
}
Reworked the way Process::RunThreadPlan and the ThreadPlanCallFunction interoperate to fix problems where hitting auto-continue signals while running a thread plan would cause us to lose control of the debug session. <rdar://problem/12993641> llvm-svn: 174793
2013-02-09 09:29:05 +08:00
If the ThreadList ShouldStop restarts the target, don't resume it again. llvm-svn: 163245
2012-09-06 05:13:56 +08:00
if (!was_restarted)
Reworked the way Process::RunThreadPlan and the ThreadPlanCallFunction interoperate to fix problems where hitting auto-continue signals while running a thread plan would cause us to lose control of the debug session. <rdar://problem/12993641> llvm-svn: 174793
2013-02-09 09:29:05 +08:00
{
if (log)
log->Printf ("Process::ShouldBroadcastEvent (%p) Restarting process from state: %s", event_ptr, StateAsCString(state));
ProcessEventData::SetRestartedInEvent(event_ptr, true);
If the ThreadList ShouldStop restarts the target, don't resume it again. llvm-svn: 163245
2012-09-06 05:13:56 +08:00
PrivateResume ();
Reworked the way Process::RunThreadPlan and the ThreadPlanCallFunction interoperate to fix problems where hitting auto-continue signals while running a thread plan would cause us to lose control of the debug session. <rdar://problem/12993641> llvm-svn: 174793
2013-02-09 09:29:05 +08:00
}
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
else
{
return_value = true;
SynchronouslyNotifyStateChanged (state);
}
}
}
Reworked the way Process::RunThreadPlan and the ThreadPlanCallFunction interoperate to fix problems where hitting auto-continue signals while running a thread plan would cause us to lose control of the debug session. <rdar://problem/12993641> llvm-svn: 174793
2013-02-09 09:29:05 +08:00
break;
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
Reworked the way Process::RunThreadPlan and the ThreadPlanCallFunction interoperate to fix problems where hitting auto-continue signals while running a thread plan would cause us to lose control of the debug session. <rdar://problem/12993641> llvm-svn: 174793
2013-02-09 09:29:05 +08:00
// 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;
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
if (log)
Reworked the way Process::RunThreadPlan and the ThreadPlanCallFunction interoperate to fix problems where hitting auto-continue signals while running a thread plan would cause us to lose control of the debug session. <rdar://problem/12993641> llvm-svn: 174793
2013-02-09 09:29:05 +08:00
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");
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
return return_value;
}
bool
We sometimes need to be able to call functions (via Process::RunThreadPlan) from code run on the private state thread. To do that we have to spin up a temporary "private state thread" that will respond to events from the lower level process plugins. This check-in should work to do that, but it is still buggy. However, if you don't call functions on the private state thread, these changes make no difference. This patch also moves the code in the AppleObjCRuntime step-through-trampoline handler that might call functions (in the case where the debug server doesn't support the memory allocate/deallocate packet) out to a safe place to do that call. llvm-svn: 154230
2012-04-07 08:00:41 +08:00
Process::StartPrivateStateThread (bool force)
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
{
<rdar://problem/13521159> LLDB is crashing when logging is enabled from lldb-perf-clang. This has to do with the global destructor chain as the process and its threads are being torn down. All logging channels now make one and only one instance that is kept in a global pointer which is never freed. This guarantees that logging can correctly continue as the process tears itself down. llvm-svn: 178191
2013-03-28 07:08:40 +08:00
Log *log(lldb_private::GetLogIfAllCategoriesSet(LIBLLDB_LOG_EVENTS));
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +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
bool already_running = PrivateStateThreadIsValid ();
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
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");
We sometimes need to be able to call functions (via Process::RunThreadPlan) from code run on the private state thread. To do that we have to spin up a temporary "private state thread" that will respond to events from the lower level process plugins. This check-in should work to do that, but it is still buggy. However, if you don't call functions on the private state thread, these changes make no difference. This patch also moves the code in the AppleObjCRuntime step-through-trampoline handler that might call functions (in the case where the debug server doesn't support the memory allocate/deallocate packet) out to a safe place to do that call. llvm-svn: 154230
2012-04-07 08:00:41 +08:00
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;
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
// 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];
We sometimes need to be able to call functions (via Process::RunThreadPlan) from code run on the private state thread. To do that we have to spin up a temporary "private state thread" that will respond to events from the lower level process plugins. This check-in should work to do that, but it is still buggy. However, if you don't call functions on the private state thread, these changes make no difference. This patch also moves the code in the AppleObjCRuntime step-through-trampoline handler that might call functions (in the case where the debug server doesn't support the memory allocate/deallocate packet) out to a safe place to do that call. llvm-svn: 154230
2012-04-07 08:00:41 +08:00
if (already_running)
Resolve printf formatting warnings on Linux: - use macros from inttypes.h for format strings instead of OS-specific types Patch from Matt Kopec! llvm-svn: 168945
2012-11-30 05:49:15 +08:00
snprintf(thread_name, sizeof(thread_name), "<lldb.process.internal-state-override(pid=%" PRIu64 ")>", GetID());
We sometimes need to be able to call functions (via Process::RunThreadPlan) from code run on the private state thread. To do that we have to spin up a temporary "private state thread" that will respond to events from the lower level process plugins. This check-in should work to do that, but it is still buggy. However, if you don't call functions on the private state thread, these changes make no difference. This patch also moves the code in the AppleObjCRuntime step-through-trampoline handler that might call functions (in the case where the debug server doesn't support the memory allocate/deallocate packet) out to a safe place to do that call. llvm-svn: 154230
2012-04-07 08:00:41 +08:00
else
Resolve printf formatting warnings on Linux: - use macros from inttypes.h for format strings instead of OS-specific types Patch from Matt Kopec! llvm-svn: 168945
2012-11-30 05:49:15 +08:00
snprintf(thread_name, sizeof(thread_name), "<lldb.process.internal-state(pid=%" PRIu64 ")>", GetID());
Two changes, 1) Start the PrivateStateThread stopped, and then in StartPrivateStateThread, make the private state thread and then resume it before we say the thread is created. That way we know it is listening for events by the time we get out of StartPrivateStateThread. 2) Backstop running a thread plan when calling Process::RunThreadPlan on the private state thread with a ThreadPlanBase so that running the plan doesn't pass its stop events to whatever plans happen to be above us on the thread plan stack. llvm-svn: 154368
2012-04-10 09:21:57 +08:00
// 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);
Two changes, 1) Start the PrivateStateThread stopped, and then in StartPrivateStateThread, make the private state thread and then resume it before we say the thread is created. That way we know it is listening for events by the time we get out of StartPrivateStateThread. 2) Backstop running a thread plan when calling Process::RunThreadPlan on the private state thread with a ThreadPlanBase so that running the plan doesn't pass its stop events to whatever plans happen to be above us on the thread plan stack. llvm-svn: 154368
2012-04-10 09:21:57 +08:00
bool success = IS_VALID_LLDB_HOST_THREAD(m_private_state_thread);
if (success)
{
ResumePrivateStateThread();
return true;
}
else
return false;
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
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);
Make sure that DoResume doesn't stall if we shut down the async thread while DoResume is waiting for packet confirmation. Also added a bit more logging. Also, unlock the writer end of the run lock in Process.cpp on our way out of the private state thread so that the Process can shut down cleanly. <rdar://problem/11228538> llvm-svn: 154601
2012-04-13 02:49:31 +08:00
else
{
<rdar://problem/13521159> LLDB is crashing when logging is enabled from lldb-perf-clang. This has to do with the global destructor chain as the process and its threads are being torn down. All logging channels now make one and only one instance that is kept in a global pointer which is never freed. This guarantees that logging can correctly continue as the process tears itself down. llvm-svn: 178191
2013-03-28 07:08:40 +08:00
Log *log(lldb_private::GetLogIfAllCategoriesSet(LIBLLDB_LOG_PROCESS));
Make sure that DoResume doesn't stall if we shut down the async thread while DoResume is waiting for packet confirmation. Also added a bit more logging. Also, unlock the writer end of the run lock in Process.cpp on our way out of the private state thread so that the Process can shut down cleanly. <rdar://problem/11228538> llvm-svn: 154601
2012-04-13 02:49:31 +08:00
if (log)
Reworked the way Process::RunThreadPlan and the ThreadPlanCallFunction interoperate to fix problems where hitting auto-continue signals while running a thread plan would cause us to lose control of the debug session. <rdar://problem/12993641> llvm-svn: 174793
2013-02-09 09:29:05 +08:00
log->Printf ("Went to stop the private state thread, but it was already invalid.");
Make sure that DoResume doesn't stall if we shut down the async thread while DoResume is waiting for packet confirmation. Also added a bit more logging. Also, unlock the writer end of the run lock in Process.cpp on our way out of the private state thread so that the Process can shut down cleanly. <rdar://problem/11228538> llvm-svn: 154601
2012-04-13 02:49:31 +08:00
}
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
void
Process::ControlPrivateStateThread (uint32_t signal)
{
<rdar://problem/13521159> LLDB is crashing when logging is enabled from lldb-perf-clang. This has to do with the global destructor chain as the process and its threads are being torn down. All logging channels now make one and only one instance that is kept in a global pointer which is never freed. This guarantees that logging can correctly continue as the process tears itself down. llvm-svn: 178191
2013-03-28 07:08:40 +08:00
Log *log(lldb_private::GetLogIfAllCategoriesSet(LIBLLDB_LOG_PROCESS));
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
assert (signal == eBroadcastInternalStateControlStop ||
signal == eBroadcastInternalStateControlPause ||
signal == eBroadcastInternalStateControlResume);
if (log)
Avoid the race condition Stephen Wilson was worried about in revision 123465 by making a local copy. We need to be able to have the private state thread let the lldb_private::Process class that it has exited, otherwise we end up with a timeout when the process destructor or DoDestroy is called where the private state thread has already exited and then StopPrivateStateThread() will wait for the thread which has already existed to respond to it. llvm-svn: 124038
2011-01-23 01:43:17 +08:00
log->Printf ("Process::%s (signal = %d)", __FUNCTION__, signal);
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
Avoid the race condition Stephen Wilson was worried about in revision 123465 by making a local copy. We need to be able to have the private state thread let the lldb_private::Process class that it has exited, otherwise we end up with a timeout when the process destructor or DoDestroy is called where the private state thread has already exited and then StopPrivateStateThread() will wait for the thread which has already existed to respond to it. llvm-svn: 124038
2011-01-23 01:43:17 +08:00
// 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;
Patch that allows for thread_t to be something more complex than an integer. Modified patch from Kirk Beitz. llvm-svn: 125067
2011-02-08 09:34:25 +08:00
if (IS_VALID_LLDB_HOST_THREAD(private_state_thread))
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
{
TimeValue timeout_time;
bool timed_out;
m_private_state_control_broadcaster.BroadcastEvent (signal, NULL);
timeout_time = TimeValue::Now();
timeout_time.OffsetWithSeconds(2);
Make sure that DoResume doesn't stall if we shut down the async thread while DoResume is waiting for packet confirmation. Also added a bit more logging. Also, unlock the writer end of the run lock in Process.cpp on our way out of the private state thread so that the Process can shut down cleanly. <rdar://problem/11228538> llvm-svn: 154601
2012-04-13 02:49:31 +08:00
if (log)
log->Printf ("Sending control event of type: %d.", signal);
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
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)
Make sure that DoResume doesn't stall if we shut down the async thread while DoResume is waiting for packet confirmation. Also added a bit more logging. Also, unlock the writer end of the run lock in Process.cpp on our way out of the private state thread so that the Process can shut down cleanly. <rdar://problem/11228538> llvm-svn: 154601
2012-04-13 02:49:31 +08:00
{
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.");
}
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
thread_result_t result = NULL;
Avoid the race condition Stephen Wilson was worried about in revision 123465 by making a local copy. We need to be able to have the private state thread let the lldb_private::Process class that it has exited, otherwise we end up with a timeout when the process destructor or DoDestroy is called where the private state thread has already exited and then StopPrivateStateThread() will wait for the thread which has already existed to respond to it. llvm-svn: 124038
2011-01-23 01:43:17 +08:00
Host::ThreadJoin (private_state_thread, &result, NULL);
This patch changes the point at which Process::m_private_state_thread is invalidated. There was a race condition where the private thread would invalidate its own pthread_t object before the parent could perform a pthread_cancel/pthread_join sequence. Patch from Stephen Wilson. llvm-svn: 109131
2010-07-23 02:34:21 +08:00
m_private_state_thread = LLDB_INVALID_HOST_THREAD;
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
}
Make sure that DoResume doesn't stall if we shut down the async thread while DoResume is waiting for packet confirmation. Also added a bit more logging. Also, unlock the writer end of the run lock in Process.cpp on our way out of the private state thread so that the Process can shut down cleanly. <rdar://problem/11228538> llvm-svn: 154601
2012-04-13 02:49:31 +08:00
else
{
if (log)
log->Printf ("Private state thread already dead, no need to signal it to stop.");
}
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
Added an lldb_private & equivalent SB API to send an AsyncInterrupt to the event loop. Convert from calling Halt in the lldb Driver.cpp's input reader's sigint handler to sending this AsyncInterrupt so it can be handled in the event loop. If you are attaching and get an async interrupt, abort the attach attempt. Also remember to destroy the process if get interrupted while attaching. Getting this to work also required handing the eBroadcastBitInterrupt in a few more places in Process WaitForEvent & friends. <rdar://problem/10792425> llvm-svn: 160903
2012-07-28 07:57:19 +08:00
void
Process::SendAsyncInterrupt ()
{
if (PrivateStateThreadIsValid())
m_private_state_broadcaster.BroadcastEvent (Process::eBroadcastBitInterrupt, NULL);
else
BroadcastEvent (Process::eBroadcastBitInterrupt, NULL);
}
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
void
Process::HandlePrivateEvent (EventSP &event_sp)
{
<rdar://problem/13521159> LLDB is crashing when logging is enabled from lldb-perf-clang. This has to do with the global destructor chain as the process and its threads are being torn down. All logging channels now make one and only one instance that is kept in a global pointer which is never freed. This guarantees that logging can correctly continue as the process tears itself down. llvm-svn: 178191
2013-03-28 07:08:40 +08:00
Log *log(lldb_private::GetLogIfAllCategoriesSet (LIBLLDB_LOG_PROCESS));
Make sure that when if we are going to Halt while the process is in the middle of HandlePrivateEvent we wait till that is done. We need a stronger way to do this, but in practice this works and using some locking strategy is harder because Halt & HandlePrivateEvent generally happen on different threads. llvm-svn: 158042
2012-06-06 08:29:30 +08:00
m_currently_handling_event.SetValue(true, eBroadcastNever);
Added a completion action class to the Process events so that we can make things like Attach and later Launch start their job, and then return to the event loop while waiting for the work to be done. llvm-svn: 124520
2011-01-29 09:49:25 +08:00
Fixed ProcessGDBRemote to kill the process correctly when it is either running or stopped. Added support for sections to be able to state if they are encrypted or not. llvm-svn: 124171
2011-01-25 10:58:48 +08:00
const StateType new_state = Process::ProcessEventData::GetStateFromEvent(event_sp.get());
Added a completion action class to the Process events so that we can make things like Attach and later Launch start their job, and then return to the event loop while waiting for the work to be done. llvm-svn: 124520
2011-01-29 09:49:25 +08:00
// First check to see if anybody wants a shot at this event:
The m_next_action is simpler if it is an auto_pointer. llvm-svn: 124525
2011-01-29 12:05:41 +08:00
if (m_next_event_action_ap.get() != NULL)
Added a completion action class to the Process events so that we can make things like Attach and later Launch start their job, and then return to the event loop while waiting for the work to be done. llvm-svn: 124520
2011-01-29 09:49:25 +08:00
{
The m_next_action is simpler if it is an auto_pointer. llvm-svn: 124525
2011-01-29 12:05:41 +08:00
NextEventAction::EventActionResult action_result = m_next_event_action_ap->PerformAction(event_sp);
Reworked the way Process::RunThreadPlan and the ThreadPlanCallFunction interoperate to fix problems where hitting auto-continue signals while running a thread plan would cause us to lose control of the debug session. <rdar://problem/12993641> llvm-svn: 174793
2013-02-09 09:29:05 +08:00
if (log)
log->Printf ("Ran next event action, result was %d.", action_result);
Added a completion action class to the Process events so that we can make things like Attach and later Launch start their job, and then return to the event loop while waiting for the work to be done. llvm-svn: 124520
2011-01-29 09:49:25 +08:00
switch (action_result)
{
case NextEventAction::eEventActionSuccess:
SetNextEventAction(NULL);
break;
Added the ability to run a process in a shell on MacOSX currently when using the --tty option. So you can now get shell expansion and file redirection: (lldb) process launch --tty --shell -- *.jpg < in.txt > out.txt Again, the "--tty" is mandatory for now until we hook this up to other functions. The shell is also currently hard coded to "/bin/bash" and not the "SHELL" variable. "/bin/tcsh" was causing problems which I need to dig into. llvm-svn: 144443
2011-11-12 10:10:56 +08:00
Added a completion action class to the Process events so that we can make things like Attach and later Launch start their job, and then return to the event loop while waiting for the work to be done. llvm-svn: 124520
2011-01-29 09:49:25 +08:00
case NextEventAction::eEventActionRetry:
break;
Added the ability to run a process in a shell on MacOSX currently when using the --tty option. So you can now get shell expansion and file redirection: (lldb) process launch --tty --shell -- *.jpg < in.txt > out.txt Again, the "--tty" is mandatory for now until we hook this up to other functions. The shell is also currently hard coded to "/bin/bash" and not the "SHELL" variable. "/bin/tcsh" was causing problems which I need to dig into. llvm-svn: 144443
2011-11-12 10:10:56 +08:00
Added a completion action class to the Process events so that we can make things like Attach and later Launch start their job, and then return to the event loop while waiting for the work to be done. llvm-svn: 124520
2011-01-29 09:49:25 +08:00
case NextEventAction::eEventActionExit:
Handle the case where the "NextEventAction" wants to kill us on some event other than eStateExited. llvm-svn: 124521
2011-01-29 09:57:31 +08:00
// 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.
The m_next_action is simpler if it is an auto_pointer. llvm-svn: 124525
2011-01-29 12:05:41 +08:00
SetExitStatus(0, m_next_event_action_ap->GetExitString());
Handle the case where the "NextEventAction" wants to kill us on some event other than eStateExited. llvm-svn: 124521
2011-01-29 09:57:31 +08:00
SetNextEventAction(NULL);
return;
}
SetNextEventAction(NULL);
Added a completion action class to the Process events so that we can make things like Attach and later Launch start their job, and then return to the event loop while waiting for the work to be done. llvm-svn: 124520
2011-01-29 09:49:25 +08:00
break;
}
}
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
// See if we should broadcast this state to external clients?
const bool should_broadcast = ShouldBroadcastEvent (event_sp.get());
if (should_broadcast)
{
if (log)
{
Resolve printf formatting warnings on Linux: - use macros from inttypes.h for format strings instead of OS-specific types Patch from Matt Kopec! llvm-svn: 168945
2012-11-30 05:49:15 +08:00
log->Printf ("Process::%s (pid = %" PRIu64 ") broadcasting new state %s (old state %s) to %s",
Fixed ProcessGDBRemote to kill the process correctly when it is either running or stopped. Added support for sections to be able to state if they are encrypted or not. llvm-svn: 124171
2011-01-25 10:58:48 +08:00
__FUNCTION__,
GetID(),
StateAsCString(new_state),
StateAsCString (GetState ()),
IsHijackedForEvent(eBroadcastBitStateChanged) ? "hijacked" : "public");
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
Add a first pass at a "stop hook" mechanism. This allows you to add commands that get run every time the debugger stops, whether due to a breakpoint, the end of a step, interrupt, etc. You can also specify in which context you want the stop hook to run, for instance only on a particular thread, or only in a particular shared library, function, file, line range within a file. Still need to add "in methods of a class" to the specifiers, and the ability to write the stop hooks in the Scripting language as well as in the Command Language. llvm-svn: 127457
2011-03-11 11:53:59 +08:00
Process::ProcessEventData::SetUpdateStateOnRemoval(event_sp.get());
Fixed ProcessGDBRemote to kill the process correctly when it is either running or stopped. Added support for sections to be able to state if they are encrypted or not. llvm-svn: 124171
2011-01-25 10:58:48 +08:00
if (StateIsRunningState (new_state))
Make processes use InputReaders for their input. Move the process ReadThread stuff into the main Process class (out of the Process Plugins). This has the (intended) side effect of disabling the command line tool from reading input/commands while the process is running (the input is directed to the running process rather than to the command interpreter). llvm-svn: 119329
2010-11-16 13:07:41 +08:00
PushProcessInputReader ();
else
PopProcessInputReader ();
Add a first pass at a "stop hook" mechanism. This allows you to add commands that get run every time the debugger stops, whether due to a breakpoint, the end of a step, interrupt, etc. You can also specify in which context you want the stop hook to run, for instance only on a particular thread, or only in a particular shared library, function, file, line range within a file. Still need to add "in methods of a class" to the specifiers, and the ability to write the stop hooks in the Scripting language as well as in the Command Language. llvm-svn: 127457
2011-03-11 11:53:59 +08:00
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
BroadcastEvent (event_sp);
}
else
{
if (log)
{
Resolve printf formatting warnings on Linux: - use macros from inttypes.h for format strings instead of OS-specific types Patch from Matt Kopec! llvm-svn: 168945
2012-11-30 05:49:15 +08:00
log->Printf ("Process::%s (pid = %" PRIu64 ") suppressing state %s (old state %s): should_broadcast == false",
Fixed ProcessGDBRemote to kill the process correctly when it is either running or stopped. Added support for sections to be able to state if they are encrypted or not. llvm-svn: 124171
2011-01-25 10:58:48 +08:00
__FUNCTION__,
GetID(),
StateAsCString(new_state),
Update declarations for all functions/methods that accept printf-style stdarg formats to use __attribute__ format so the compiler can flag incorrect uses. Fix all incorrect uses. Most of these are innocuous, a few were resulting in crashes. llvm-svn: 140185
2011-09-21 05:44:10 +08:00
StateAsCString (GetState ()));
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
}
Make sure that when if we are going to Halt while the process is in the middle of HandlePrivateEvent we wait till that is done. We need a stronger way to do this, but in practice this works and using some locking strategy is harder because Halt & HandlePrivateEvent generally happen on different threads. llvm-svn: 158042
2012-06-06 08:29:30 +08:00
m_currently_handling_event.SetValue(false, eBroadcastAlways);
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
void *
Process::PrivateStateThread (void *arg)
{
Process *proc = static_cast<Process*> (arg);
void *result = proc->RunPrivateStateThread ();
return result;
}
void *
Process::RunPrivateStateThread ()
{
Two changes, 1) Start the PrivateStateThread stopped, and then in StartPrivateStateThread, make the private state thread and then resume it before we say the thread is created. That way we know it is listening for events by the time we get out of StartPrivateStateThread. 2) Backstop running a thread plan when calling Process::RunThreadPlan on the private state thread with a ThreadPlanBase so that running the plan doesn't pass its stop events to whatever plans happen to be above us on the thread plan stack. llvm-svn: 154368
2012-04-10 09:21:57 +08:00
bool control_only = true;
Make sure that DoResume doesn't stall if we shut down the async thread while DoResume is waiting for packet confirmation. Also added a bit more logging. Also, unlock the writer end of the run lock in Process.cpp on our way out of the private state thread so that the Process can shut down cleanly. <rdar://problem/11228538> llvm-svn: 154601
2012-04-13 02:49:31 +08:00
m_private_state_control_wait.SetValue (false, eBroadcastNever);
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
<rdar://problem/13521159> LLDB is crashing when logging is enabled from lldb-perf-clang. This has to do with the global destructor chain as the process and its threads are being torn down. All logging channels now make one and only one instance that is kept in a global pointer which is never freed. This guarantees that logging can correctly continue as the process tears itself down. llvm-svn: 178191
2013-03-28 07:08:40 +08:00
Log *log(lldb_private::GetLogIfAllCategoriesSet (LIBLLDB_LOG_PROCESS));
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
if (log)
Resolve printf formatting warnings on Linux: - use macros from inttypes.h for format strings instead of OS-specific types Patch from Matt Kopec! llvm-svn: 168945
2012-11-30 05:49:15 +08:00
log->Printf ("Process::%s (arg = %p, pid = %" PRIu64 ") thread starting...", __FUNCTION__, this, GetID());
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
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))
{
Make sure that DoResume doesn't stall if we shut down the async thread while DoResume is waiting for packet confirmation. Also added a bit more logging. Also, unlock the writer end of the run lock in Process.cpp on our way out of the private state thread so that the Process can shut down cleanly. <rdar://problem/11228538> llvm-svn: 154601
2012-04-13 02:49:31 +08:00
if (log)
Resolve printf formatting warnings on Linux: - use macros from inttypes.h for format strings instead of OS-specific types Patch from Matt Kopec! llvm-svn: 168945
2012-11-30 05:49:15 +08:00
log->Printf ("Process::%s (arg = %p, pid = %" PRIu64 ") got a control event: %d", __FUNCTION__, this, GetID(), event_sp->GetType());
Make sure that DoResume doesn't stall if we shut down the async thread while DoResume is waiting for packet confirmation. Also added a bit more logging. Also, unlock the writer end of the run lock in Process.cpp on our way out of the private state thread so that the Process can shut down cleanly. <rdar://problem/11228538> llvm-svn: 154601
2012-04-13 02:49:31 +08:00
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
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;
}
Added an "Interrupted" bit to the ProcessEventData. Halt now generates an event with the Interrupted bit set. Process::HandlePrivateEvent ignores Interrupted events. DoHalt is changed to ensure that the stop even is processed, and an event with the Interrupted event is posted. Finally ClangFunction is rationalized to use this facility so the that Halt is handled more deterministically. llvm-svn: 119453
2010-11-17 10:32:00 +08:00
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
m_private_state_control_wait.SetValue (true, eBroadcastAlways);
Added an "Interrupted" bit to the ProcessEventData. Halt now generates an event with the Interrupted bit set. Process::HandlePrivateEvent ignores Interrupted events. DoHalt is changed to ensure that the stop even is processed, and an event with the Interrupted event is posted. Finally ClangFunction is rationalized to use this facility so the that Halt is handled more deterministically. llvm-svn: 119453
2010-11-17 10:32:00 +08:00
continue;
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
Added an lldb_private & equivalent SB API to send an AsyncInterrupt to the event loop. Convert from calling Halt in the lldb Driver.cpp's input reader's sigint handler to sending this AsyncInterrupt so it can be handled in the event loop. If you are attaching and get an async interrupt, abort the attach attempt. Also remember to destroy the process if get interrupted while attaching. Getting this to work also required handing the eBroadcastBitInterrupt in a few more places in Process WaitForEvent & friends. <rdar://problem/10792425> llvm-svn: 160903
2012-07-28 07:57:19 +08:00
else if (event_sp->GetType() == eBroadcastBitInterrupt)
{
if (m_public_state.GetValue() == eStateAttaching)
{
if (log)
Resolve printf formatting warnings on Linux: - use macros from inttypes.h for format strings instead of OS-specific types Patch from Matt Kopec! llvm-svn: 168945
2012-11-30 05:49:15 +08:00
log->Printf ("Process::%s (arg = %p, pid = %" PRIu64 ") woke up with an interrupt while attaching - forwarding interrupt.", __FUNCTION__, this, GetID());
Added an lldb_private & equivalent SB API to send an AsyncInterrupt to the event loop. Convert from calling Halt in the lldb Driver.cpp's input reader's sigint handler to sending this AsyncInterrupt so it can be handled in the event loop. If you are attaching and get an async interrupt, abort the attach attempt. Also remember to destroy the process if get interrupted while attaching. Getting this to work also required handing the eBroadcastBitInterrupt in a few more places in Process WaitForEvent & friends. <rdar://problem/10792425> llvm-svn: 160903
2012-07-28 07:57:19 +08:00
BroadcastEvent (eBroadcastBitInterrupt, NULL);
}
else
{
if (log)
Resolve printf formatting warnings on Linux: - use macros from inttypes.h for format strings instead of OS-specific types Patch from Matt Kopec! llvm-svn: 168945
2012-11-30 05:49:15 +08:00
log->Printf ("Process::%s (arg = %p, pid = %" PRIu64 ") woke up with an interrupt - Halting.", __FUNCTION__, this, GetID());
Added an lldb_private & equivalent SB API to send an AsyncInterrupt to the event loop. Convert from calling Halt in the lldb Driver.cpp's input reader's sigint handler to sending this AsyncInterrupt so it can be handled in the event loop. If you are attaching and get an async interrupt, abort the attach attempt. Also remember to destroy the process if get interrupted while attaching. Getting this to work also required handing the eBroadcastBitInterrupt in a few more places in Process WaitForEvent & friends. <rdar://problem/10792425> llvm-svn: 160903
2012-07-28 07:57:19 +08:00
Halt();
}
continue;
}
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
const StateType internal_state = Process::ProcessEventData::GetStateFromEvent(event_sp.get());
if (internal_state != eStateInvalid)
{
HandlePrivateEvent (event_sp);
}
Still trying to get detach to work with debugserver. Got a bit closer, but something is still killing our inferior. Fixed an issue with darwin-debug where it wasn't passing all needed arguments to the inferior. Fixed a race condition with the attach to named process code. llvm-svn: 116697
2010-10-18 12:14:23 +08:00
if (internal_state == eStateInvalid ||
internal_state == eStateExited ||
internal_state == eStateDetached )
Added an "Interrupted" bit to the ProcessEventData. Halt now generates an event with the Interrupted bit set. Process::HandlePrivateEvent ignores Interrupted events. DoHalt is changed to ensure that the stop even is processed, and an event with the Interrupted event is posted. Finally ClangFunction is rationalized to use this facility so the that Halt is handled more deterministically. llvm-svn: 119453
2010-11-17 10:32:00 +08:00
{
if (log)
Resolve printf formatting warnings on Linux: - use macros from inttypes.h for format strings instead of OS-specific types Patch from Matt Kopec! llvm-svn: 168945
2012-11-30 05:49:15 +08:00
log->Printf ("Process::%s (arg = %p, pid = %" PRIu64 ") about to exit with internal state %s...", __FUNCTION__, this, GetID(), StateAsCString(internal_state));
Added an "Interrupted" bit to the ProcessEventData. Halt now generates an event with the Interrupted bit set. Process::HandlePrivateEvent ignores Interrupted events. DoHalt is changed to ensure that the stop even is processed, and an event with the Interrupted event is posted. Finally ClangFunction is rationalized to use this facility so the that Halt is handled more deterministically. llvm-svn: 119453
2010-11-17 10:32:00 +08:00
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
break;
Added an "Interrupted" bit to the ProcessEventData. Halt now generates an event with the Interrupted bit set. Process::HandlePrivateEvent ignores Interrupted events. DoHalt is changed to ensure that the stop even is processed, and an event with the Interrupted event is posted. Finally ClangFunction is rationalized to use this facility so the that Halt is handled more deterministically. llvm-svn: 119453
2010-11-17 10:32:00 +08:00
}
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
Add the ability to disable individual log categories, rather than just the entire log channel. Add checks, where appropriate, to make sure a log channel/category has not been disabled before attempting to write to it. llvm-svn: 117715
2010-10-30 05:48:37 +08:00
// Verify log is still enabled before attempting to write to it...
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
if (log)
Resolve printf formatting warnings on Linux: - use macros from inttypes.h for format strings instead of OS-specific types Patch from Matt Kopec! llvm-svn: 168945
2012-11-30 05:49:15 +08:00
log->Printf ("Process::%s (arg = %p, pid = %" PRIu64 ") thread exiting...", __FUNCTION__, this, GetID());
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
Sped up the shutdown time on MacOSX by quite a bit by making sure any threads that we spawn let us know when they are going away and that we don't timeout waiting for a message from threads that have gone away. We also now don't expect the "k" packet (kill) to send a response. This greatly speeds up debugger shutdown performance. The test suite now runs quite a bit faster. Added a fix to the variable display code that fixes the display of base classes. We were assuming the virtual or normal base class offsets were being given in bit sizes, but they were being given as character sizes, so we needed to multiply the offset by 8. This wasn't affecting the expression parser, but it was affecting the correct display of C++ class base classes and all of their children. llvm-svn: 124024
2011-01-22 15:12:45 +08:00
m_private_state_control_wait.SetValue (true, eBroadcastAlways);
m_private_state_thread = LLDB_INVALID_HOST_THREAD;
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
return NULL;
}
//------------------------------------------------------------------
// Process Event Data
//------------------------------------------------------------------
Process::ProcessEventData::ProcessEventData () :
EventData (),
m_process_sp (),
m_state (eStateInvalid),
Merged Eli Friedman's linux build changes where he added Makefile files that enabled LLVM make style building and made this compile LLDB on Mac OS X. We can now iterate on this to make the build work on both linux and macosx. llvm-svn: 108009
2010-07-10 04:39:50 +08:00
m_restarted (false),
Change the m_update_state to an int, and only trigger the "on removal" action the second time the event is removed (the first is the internal -> external transition, the second when it is pulled off the public event queue, and further times when it is put back because we are faking a stop reason to hide the expression evaluation stops. llvm-svn: 131869
2011-05-23 05:45:01 +08:00
m_update_state (0),
Added an "Interrupted" bit to the ProcessEventData. Halt now generates an event with the Interrupted bit set. Process::HandlePrivateEvent ignores Interrupted events. DoHalt is changed to ensure that the stop even is processed, and an event with the Interrupted event is posted. Finally ClangFunction is rationalized to use this facility so the that Halt is handled more deterministically. llvm-svn: 119453
2010-11-17 10:32:00 +08:00
m_interrupted (false)
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
{
}
Process::ProcessEventData::ProcessEventData (const ProcessSP &process_sp, StateType state) :
EventData (),
m_process_sp (process_sp),
m_state (state),
Merged Eli Friedman's linux build changes where he added Makefile files that enabled LLVM make style building and made this compile LLDB on Mac OS X. We can now iterate on this to make the build work on both linux and macosx. llvm-svn: 108009
2010-07-10 04:39:50 +08:00
m_restarted (false),
Change the m_update_state to an int, and only trigger the "on removal" action the second time the event is removed (the first is the internal -> external transition, the second when it is pulled off the public event queue, and further times when it is put back because we are faking a stop reason to hide the expression evaluation stops. llvm-svn: 131869
2011-05-23 05:45:01 +08:00
m_update_state (0),
Added an "Interrupted" bit to the ProcessEventData. Halt now generates an event with the Interrupted bit set. Process::HandlePrivateEvent ignores Interrupted events. DoHalt is changed to ensure that the stop even is processed, and an event with the Interrupted event is posted. Finally ClangFunction is rationalized to use this facility so the that Halt is handled more deterministically. llvm-svn: 119453
2010-11-17 10:32:00 +08:00
m_interrupted (false)
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
{
}
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
Change the m_update_state to an int, and only trigger the "on removal" action the second time the event is removed (the first is the internal -> external transition, the second when it is pulled off the public event queue, and further times when it is put back because we are faking a stop reason to hide the expression evaluation stops. llvm-svn: 131869
2011-05-23 05:45:01 +08:00
// 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,
// and > 1 for expression evaluation, and we don't want to do the breakpoint command handling then.
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
Change the m_update_state to an int, and only trigger the "on removal" action the second time the event is removed (the first is the internal -> external transition, the second when it is pulled off the public event queue, and further times when it is put back because we are faking a stop reason to hide the expression evaluation stops. llvm-svn: 131869
2011-05-23 05:45:01 +08:00
if (m_update_state != 1)
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
return;
Reworked the way Process::RunThreadPlan and the ThreadPlanCallFunction interoperate to fix problems where hitting auto-continue signals while running a thread plan would cause us to lose control of the debug session. <rdar://problem/12993641> llvm-svn: 174793
2013-02-09 09:29:05 +08:00
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
m_process_sp->SetPublicState (m_state);
// If we're stopped and haven't restarted, then do the breakpoint commands here:
if (m_state == eStateStopped && ! m_restarted)
Do a better job of detecting when a breakpoint command has set the target running again (except you have to ignore cases where the breakpoint runs expressions, those don't count as really "running again"). llvm-svn: 144064
2011-11-08 11:00:11 +08:00
{
ThreadList &curr_thread_list = m_process_sp->GetThreadList();
Process IDs (lldb::pid_t) and thread IDs (lldb::tid_t) are now 64 bit. This will allow us to represent a process/thread ID using a pointer for the OS plug-ins where they might want to represent the process or thread ID using the address of the process or thread structure. llvm-svn: 145644
2011-12-02 07:28:38 +08:00
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
Move the handling of breakpoint conditions from the Private event loop to the StopInfoBreakpoint::DoActions, which happens as the event is removed. Also use the return value of asynchronous breakpoint callbacks, they get checked before, and override the breakpoint conditions. Added ProcessModInfo class, to unify "stop_id generation" and "memory modification generation", and use where needed. llvm-svn: 137102
2011-08-09 10:12:22 +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.
Do a better job of detecting when a breakpoint command has set the target running again (except you have to ignore cases where the breakpoint runs expressions, those don't count as really "running again"). llvm-svn: 144064
2011-11-08 11:00:11 +08:00
// 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.
Process IDs (lldb::pid_t) and thread IDs (lldb::tid_t) are now 64 bit. This will allow us to represent a process/thread ID using a pointer for the OS plug-ins where they might want to represent the process or thread ID using the address of the process or thread structure. llvm-svn: 145644
2011-12-02 07:28:38 +08:00
std::vector<uint32_t> thread_index_array(num_threads);
Do a better job of detecting when a breakpoint command has set the target running again (except you have to ignore cases where the breakpoint runs expressions, those don't count as really "running again"). llvm-svn: 144064
2011-11-08 11:00:11 +08:00
for (idx = 0; idx < num_threads; ++idx)
thread_index_array[idx] = curr_thread_list.GetThreadAtIndex(idx)->GetIndexID();
Fixed a thinko in the handling of the case where more than one thread had stopped with real stop reasons at the same time. Should be that if any of the threads wants to stop, we should stop. The opposite was what was actually happening <rdar://problem/12869725> llvm-svn: 170153
2012-12-14 06:24:15 +08:00
// 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;
Move the handling of breakpoint conditions from the Private event loop to the StopInfoBreakpoint::DoActions, which happens as the event is removed. Also use the return value of asynchronous breakpoint callbacks, they get checked before, and override the breakpoint conditions. Added ProcessModInfo class, to unify "stop_id generation" and "memory modification generation", and use where needed. llvm-svn: 137102
2011-08-09 10:12:22 +08:00
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
for (idx = 0; idx < num_threads; ++idx)
{
Do a better job of detecting when a breakpoint command has set the target running again (except you have to ignore cases where the breakpoint runs expressions, those don't count as really "running again"). llvm-svn: 144064
2011-11-08 11:00:11 +08:00
curr_thread_list = m_process_sp->GetThreadList();
if (curr_thread_list.GetSize() != num_threads)
{
<rdar://problem/13521159> LLDB is crashing when logging is enabled from lldb-perf-clang. This has to do with the global destructor chain as the process and its threads are being torn down. All logging channels now make one and only one instance that is kept in a global pointer which is never freed. This guarantees that logging can correctly continue as the process tears itself down. llvm-svn: 178191
2013-03-28 07:08:40 +08:00
Log *log(lldb_private::GetLogIfAnyCategoriesSet (LIBLLDB_LOG_STEP | LIBLLDB_LOG_PROCESS));
Protect a few log->Printf calls with "if (log)"... llvm-svn: 145625
2011-12-02 04:26:15 +08:00
if (log)
Process IDs (lldb::pid_t) and thread IDs (lldb::tid_t) are now 64 bit. This will allow us to represent a process/thread ID using a pointer for the OS plug-ins where they might want to represent the process or thread ID using the address of the process or thread structure. llvm-svn: 145644
2011-12-02 07:28:38 +08:00
log->Printf("Number of threads changed from %u to %u while processing event.", num_threads, curr_thread_list.GetSize());
Do a better job of detecting when a breakpoint command has set the target running again (except you have to ignore cases where the breakpoint runs expressions, those don't count as really "running again"). llvm-svn: 144064
2011-11-08 11:00:11 +08:00
break;
}
lldb::ThreadSP thread_sp = curr_thread_list.GetThreadAtIndex(idx);
if (thread_sp->GetIndexID() != thread_index_array[idx])
{
<rdar://problem/13521159> LLDB is crashing when logging is enabled from lldb-perf-clang. This has to do with the global destructor chain as the process and its threads are being torn down. All logging channels now make one and only one instance that is kept in a global pointer which is never freed. This guarantees that logging can correctly continue as the process tears itself down. llvm-svn: 178191
2013-03-28 07:08:40 +08:00
Log *log(lldb_private::GetLogIfAnyCategoriesSet (LIBLLDB_LOG_STEP | LIBLLDB_LOG_PROCESS));
Protect a few log->Printf calls with "if (log)"... llvm-svn: 145625
2011-12-02 04:26:15 +08:00
if (log)
Process IDs (lldb::pid_t) and thread IDs (lldb::tid_t) are now 64 bit. This will allow us to represent a process/thread ID using a pointer for the OS plug-ins where they might want to represent the process or thread ID using the address of the process or thread structure. llvm-svn: 145644
2011-12-02 07:28:38 +08:00
log->Printf("The thread at position %u changed from %u to %u while processing event.",
Protect a few log->Printf calls with "if (log)"... llvm-svn: 145625
2011-12-02 04:26:15 +08:00
idx,
thread_index_array[idx],
thread_sp->GetIndexID());
Do a better job of detecting when a breakpoint command has set the target running again (except you have to ignore cases where the breakpoint runs expressions, those don't count as really "running again"). llvm-svn: 144064
2011-11-08 11:00:11 +08:00
break;
}
Don't cache the public stop reason, since it can change as plan completion gets processed. That means GetStopReason needs to return a shared pointer, not a pointer to the thread's cached version. Also allow the thread plans to get and set the thread private stop reason - that is usually more appropriate for the logic the thread plans need to do. llvm-svn: 116892
2010-10-20 08:39:53 +08:00
StopInfoSP stop_info_sp = thread_sp->GetStopInfo ();
Patch from Matt Kopec <matt.kopec@intel.com> to fix the problem that if two breakpoints were set on consecutive addresses, the continue from the first breakpoint would skip the second. llvm-svn: 166000
2012-10-16 08:09:33 +08:00
if (stop_info_sp && stop_info_sp->IsValid())
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
{
Reworked the way Process::RunThreadPlan and the ThreadPlanCallFunction interoperate to fix problems where hitting auto-continue signals while running a thread plan would cause us to lose control of the debug session. <rdar://problem/12993641> llvm-svn: 174793
2013-02-09 09:29:05 +08:00
bool this_thread_wants_to_stop;
if (stop_info_sp->GetOverrideShouldStop())
Move the handling of breakpoint conditions from the Private event loop to the StopInfoBreakpoint::DoActions, which happens as the event is removed. Also use the return value of asynchronous breakpoint callbacks, they get checked before, and override the breakpoint conditions. Added ProcessModInfo class, to unify "stop_id generation" and "memory modification generation", and use where needed. llvm-svn: 137102
2011-08-09 10:12:22 +08:00
{
Reworked the way Process::RunThreadPlan and the ThreadPlanCallFunction interoperate to fix problems where hitting auto-continue signals while running a thread plan would cause us to lose control of the debug session. <rdar://problem/12993641> llvm-svn: 174793
2013-02-09 09:29:05 +08:00
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);
Move the handling of breakpoint conditions from the Private event loop to the StopInfoBreakpoint::DoActions, which happens as the event is removed. Also use the return value of asynchronous breakpoint callbacks, they get checked before, and override the breakpoint conditions. Added ProcessModInfo class, to unify "stop_id generation" and "memory modification generation", and use where needed. llvm-svn: 137102
2011-08-09 10:12:22 +08:00
}
Fixed a thinko in the handling of the case where more than one thread had stopped with real stop reasons at the same time. Should be that if any of the threads wants to stop, we should stop. The opposite was what was actually happening <rdar://problem/12869725> llvm-svn: 170153
2012-12-14 06:24:15 +08:00
if (still_should_stop == false)
still_should_stop = this_thread_wants_to_stop;
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
}
Make breakpoint commands work again. Added a PerformAction to the stop info - actions are run when the stop event is pulled from the event queue. Then made the StopInfoBreakpoint's PerformAction do the breakpoint command. Also fixed the StopInfoBreakpoint's GetDescription so it gets the breakpoint location info, not the breakpoint site info. llvm-svn: 110637
2010-08-10 08:59:59 +08:00
Move the handling of breakpoint conditions from the Private event loop to the StopInfoBreakpoint::DoActions, which happens as the event is removed. Also use the return value of asynchronous breakpoint callbacks, they get checked before, and override the breakpoint conditions. Added ProcessModInfo class, to unify "stop_id generation" and "memory modification generation", and use where needed. llvm-svn: 137102
2011-08-09 10:12:22 +08:00
if (m_process_sp->GetPrivateState() != eStateRunning)
Add a first pass at a "stop hook" mechanism. This allows you to add commands that get run every time the debugger stops, whether due to a breakpoint, the end of a step, interrupt, etc. You can also specify in which context you want the stop hook to run, for instance only on a particular thread, or only in a particular shared library, function, file, line range within a file. Still need to add "in methods of a class" to the specifiers, and the ability to write the stop hooks in the Scripting language as well as in the Command Language. llvm-svn: 127457
2011-03-11 11:53:59 +08:00
{
Move the handling of breakpoint conditions from the Private event loop to the StopInfoBreakpoint::DoActions, which happens as the event is removed. Also use the return value of asynchronous breakpoint callbacks, they get checked before, and override the breakpoint conditions. Added ProcessModInfo class, to unify "stop_id generation" and "memory modification generation", and use where needed. llvm-svn: 137102
2011-08-09 10:12:22 +08:00
if (!still_should_stop)
{
// We've been asked to continue, so do that here.
Add a first pass at a "stop hook" mechanism. This allows you to add commands that get run every time the debugger stops, whether due to a breakpoint, the end of a step, interrupt, etc. You can also specify in which context you want the stop hook to run, for instance only on a particular thread, or only in a particular shared library, function, file, line range within a file. Still need to add "in methods of a class" to the specifiers, and the ability to write the stop hooks in the Scripting language as well as in the Command Language. llvm-svn: 127457
2011-03-11 11:53:59 +08:00
SetRestarted(true);
Switch to setting the write side of the run lock when we call Resume. Then make a PrivateResume that doesn't switch the run-lock state, and use that where we are resuming without changing the public resume state. llvm-svn: 155092
2012-04-19 09:40:33 +08:00
// Use the public resume method here, since this is just
// extending a public resume.
Reworked the way Process::RunThreadPlan and the ThreadPlanCallFunction interoperate to fix problems where hitting auto-continue signals while running a thread plan would cause us to lose control of the debug session. <rdar://problem/12993641> llvm-svn: 174793
2013-02-09 09:29:05 +08:00
m_process_sp->PrivateResume();
Move the handling of breakpoint conditions from the Private event loop to the StopInfoBreakpoint::DoActions, which happens as the event is removed. Also use the return value of asynchronous breakpoint callbacks, they get checked before, and override the breakpoint conditions. Added ProcessModInfo class, to unify "stop_id generation" and "memory modification generation", and use where needed. llvm-svn: 137102
2011-08-09 10:12:22 +08:00
}
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);
}
Add a first pass at a "stop hook" mechanism. This allows you to add commands that get run every time the debugger stops, whether due to a breakpoint, the end of a step, interrupt, etc. You can also specify in which context you want the stop hook to run, for instance only on a particular thread, or only in a particular shared library, function, file, line range within a file. Still need to add "in methods of a class" to the specifiers, and the ability to write the stop hooks in the Scripting language as well as in the Command Language. llvm-svn: 127457
2011-03-11 11:53:59 +08:00
}
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
}
void
Process::ProcessEventData::Dump (Stream *s) const
{
if (m_process_sp)
Resolve printf formatting warnings on Linux: - use macros from inttypes.h for format strings instead of OS-specific types Patch from Matt Kopec! llvm-svn: 168945
2012-11-30 05:49:15 +08:00
s->Printf(" process = %p (pid = %" PRIu64 "), ", m_process_sp.get(), m_process_sp->GetID());
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +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
s->Printf("state = %s", StateAsCString(GetState()));
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
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);
}
Reworked the way Process::RunThreadPlan and the ThreadPlanCallFunction interoperate to fix problems where hitting auto-continue signals while running a thread plan would cause us to lose control of the debug session. <rdar://problem/12993641> llvm-svn: 174793
2013-02-09 09:29:05 +08:00
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);
}
Added an "Interrupted" bit to the ProcessEventData. Halt now generates an event with the Interrupted bit set. Process::HandlePrivateEvent ignores Interrupted events. DoHalt is changed to ensure that the stop even is processed, and an event with the Interrupted event is posted. Finally ClangFunction is rationalized to use this facility so the that Halt is handled more deterministically. llvm-svn: 119453
2010-11-17 10:32:00 +08:00
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);
}
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
bool
Process::ProcessEventData::SetUpdateStateOnRemoval (Event *event_ptr)
{
ProcessEventData *data = const_cast<ProcessEventData *>(GetEventDataFromEvent (event_ptr));
if (data)
{
data->SetUpdateStateOnRemoval();
return true;
}
return false;
}
The second part in thread hardening the internals of LLDB where we make the lldb_private::StackFrame objects hold onto a weak pointer to the thread object. The lldb_private::StackFrame objects the the most volatile objects we have as when we are doing single stepping, frames can often get lost or thrown away, only to be re-created as another object that still refers to the same frame. We have another bug tracking that. But we need to be able to have frames no longer be able to get the thread when they are not part of a thread anymore, and this is the first step (this fix makes that possible but doesn't implement it yet). Also changed lldb_private::ExecutionContextScope to return shared pointers to all objects in the execution context to further thread harden the internals. llvm-svn: 150871
2012-02-18 13:35:26 +08:00
lldb::TargetSP
Process::CalculateTarget ()
{
return m_target.shared_from_this();
}
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
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)
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
{
Converted the lldb_private::Process over to use the intrusive shared pointers. Changed the ExecutionContext over to use shared pointers for the target, process, thread and frame since these objects can easily go away at any time and any object that was holding onto an ExecutionContext was running the risk of using a bad object. Now that the shared pointers for target, process, thread and frame are just a single pointer (they all use the instrusive shared pointers) the execution context is much safer and still the same size. Made the shared pointers in the the ExecutionContext class protected and made accessors for all of the various ways to get at the pointers, references, and shared pointers. llvm-svn: 140298
2011-09-22 12:58:26 +08:00
exe_ctx.SetTargetPtr (&m_target);
exe_ctx.SetProcessPtr (this);
exe_ctx.SetThreadPtr(NULL);
exe_ctx.SetFramePtr (NULL);
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
LLDB now has "Platform" plug-ins. Platform plug-ins are plug-ins that provide an interface to a local or remote debugging platform. By default each host OS that supports LLDB should be registering a "default" platform that will be used unless a new platform is selected. Platforms are responsible for things such as: - getting process information by name or by processs ID - finding platform files. This is useful for remote debugging where there is an SDK with files that might already or need to be cached for debug access. - getting a list of platform supported architectures in the exact order they should be selected. This helps the native x86 platform on MacOSX select the correct x86_64/i386 slice from universal binaries. - Connect to remote platforms for remote debugging - Resolving an executable including finding an executable inside platform specific bundles (macosx uses .app bundles that contain files) and also selecting the appropriate slice of universal files for a given platform. So by default there is always a local platform, but remote platforms can be connected to. I will soon be adding a new "platform" command that will support the following commands: (lldb) platform connect --name machine1 macosx connect://host:port Connected to "machine1" platform. (lldb) platform disconnect macosx This allows LLDB to be well setup to do remote debugging and also once connected process listing and finding for things like: (lldb) process attach --name x<TAB> The currently selected platform plug-in can now auto complete any available processes that start with "x". The responsibilities for the platform plug-in will soon grow and expand. llvm-svn: 127286
2011-03-09 06:40:15 +08:00
//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);
//}
//
Make processes use InputReaders for their input. Move the process ReadThread stuff into the main Process class (out of the Process Plugins). This has the (intended) side effect of disabling the command line tool from reading input/commands while the process is running (the input is directed to the running process rather than to the command interpreter). llvm-svn: 119329
2010-11-16 13:07:41 +08:00
void
Process::AppendSTDOUT (const char * s, size_t len)
{
Fixed Process::Halt() as it was broken for "process halt" after recent changes to the DoHalt down in ProcessGDBRemote. I also moved the functionality that was in ProcessGDBRemote::DoHalt up into Process::Halt so not every class has to implement a tricky halt/resume on the internal state thread. The functionality is the same as it was before with two changes: - when we eat the event we now just reuse the event we consume when the private state thread is paused and set the interrupted bool on the event if needed - we also properly update the Process::m_public_state with the state of the event we consume. Prior to this, if you issued a "process halt" it would eat the event, not update the process state, and then produce a new event with the interrupted bit set and send it. Anyone listening to the event would get the stopped event with a process that whose state was set to "running". Fixed debugserver to not have to be spawned with the architecture of the inferior process. This worked fine for launching processes, but when attaching to processes by name or pid without a file in lldb, it would fail. Now debugserver can support multiple architectures for a native debug session on the current host. This currently means i386 and x86_64 are supported in the same binary and a x86_64 debugserver can attach to a i386 executable. This change involved a lot of changes to make sure we dynamically detect the correct registers for the inferior process. llvm-svn: 119680
2010-11-18 13:57:03 +08:00
Mutex::Locker locker (m_stdio_communication_mutex);
Make processes use InputReaders for their input. Move the process ReadThread stuff into the main Process class (out of the Process Plugins). This has the (intended) side effect of disabling the command line tool from reading input/commands while the process is running (the input is directed to the running process rather than to the command interpreter). llvm-svn: 119329
2010-11-16 13:07:41 +08:00
m_stdout_data.append (s, len);
<rdar://problem/12500785> I tracked down a leak that could happen when detaching from a process where the lldb_private::Process objects would stay around forever. This was caused by a eStateDetached event that was queued up on the lldb_private::Process private state thread listener. Since process events contain shared pointers to the process, this is dangerous if they don't get consume or cleared as having the lldb_private::Process class contain a collection of things that have a shared pointer to yourself is obviously bad. To fix this I modified the Process::Finalize() function to clear this list. The actual thing that was holding onto the ModuleSP and thus the static archive, was a stack frame. Since the process wasn't going away, it still had thread objects and they still had frames. I modified the Thread::Destroy() to clear the stack frames to ensure this further doesn't happen. llvm-svn: 166964
2012-10-30 04:52:08 +08:00
BroadcastEventIfUnique (eBroadcastBitSTDOUT, new ProcessEventData (shared_from_this(), GetState()));
Make processes use InputReaders for their input. Move the process ReadThread stuff into the main Process class (out of the Process Plugins). This has the (intended) side effect of disabling the command line tool from reading input/commands while the process is running (the input is directed to the running process rather than to the command interpreter). llvm-svn: 119329
2010-11-16 13:07:41 +08:00
}
<rdar://problem/10103980> A long time ago we started to centralized the STDOUT in lldb_private::Process but we missed a few things still in ProcessGDBRemote. llvm-svn: 144491
2011-11-13 12:45:22 +08:00
void
Process::AppendSTDERR (const char * s, size_t len)
{
Mutex::Locker locker (m_stdio_communication_mutex);
m_stderr_data.append (s, len);
<rdar://problem/12500785> I tracked down a leak that could happen when detaching from a process where the lldb_private::Process objects would stay around forever. This was caused by a eStateDetached event that was queued up on the lldb_private::Process private state thread listener. Since process events contain shared pointers to the process, this is dangerous if they don't get consume or cleared as having the lldb_private::Process class contain a collection of things that have a shared pointer to yourself is obviously bad. To fix this I modified the Process::Finalize() function to clear this list. The actual thing that was holding onto the ModuleSP and thus the static archive, was a stack frame. Since the process wasn't going away, it still had thread objects and they still had frames. I modified the Thread::Destroy() to clear the stack frames to ensure this further doesn't happen. llvm-svn: 166964
2012-10-30 04:52:08 +08:00
BroadcastEventIfUnique (eBroadcastBitSTDERR, new ProcessEventData (shared_from_this(), GetState()));
<rdar://problem/10103980> A long time ago we started to centralized the STDOUT in lldb_private::Process but we missed a few things still in ProcessGDBRemote. llvm-svn: 144491
2011-11-13 12:45:22 +08:00
}
<rdar://problem/12720514> Sub-TLF: Provide service to profile the inferior This allows client to query profiling states on the inferior. llvm-svn: 168228
2012-11-17 08:21:04 +08:00
void
Process::BroadcastAsyncProfileData(const char *s, size_t len)
{
Mutex::Locker locker (m_profile_data_comm_mutex);
<rdar://problem/12780259> Prevent async and sync calls to get profile data from stomping on each other. At the same time, don't use '$' as end delimiter per chunk of profile data. llvm-svn: 168948
2012-11-30 06:14:45 +08:00
m_profile_data.push_back(s);
<rdar://problem/12720514> Sub-TLF: Provide service to profile the inferior This allows client to query profiling states on the inferior. llvm-svn: 168228
2012-11-17 08:21:04 +08:00
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);
<rdar://problem/12780259> Prevent async and sync calls to get profile data from stomping on each other. At the same time, don't use '$' as end delimiter per chunk of profile data. llvm-svn: 168948
2012-11-30 06:14:45 +08:00
if (m_profile_data.empty())
return 0;
size_t bytes_available = m_profile_data.front().size();
<rdar://problem/12720514> Sub-TLF: Provide service to profile the inferior This allows client to query profiling states on the inferior. llvm-svn: 168228
2012-11-17 08:21:04 +08:00
if (bytes_available > 0)
{
<rdar://problem/13521159> LLDB is crashing when logging is enabled from lldb-perf-clang. This has to do with the global destructor chain as the process and its threads are being torn down. All logging channels now make one and only one instance that is kept in a global pointer which is never freed. This guarantees that logging can correctly continue as the process tears itself down. llvm-svn: 178191
2013-03-28 07:08:40 +08:00
Log *log (lldb_private::GetLogIfAllCategoriesSet (LIBLLDB_LOG_PROCESS));
<rdar://problem/12720514> Sub-TLF: Provide service to profile the inferior This allows client to query profiling states on the inferior. llvm-svn: 168228
2012-11-17 08:21:04 +08:00
if (log)
Resolve printf formatting warnings on Linux: - use macros from inttypes.h for format strings instead of OS-specific types Patch from Matt Kopec! llvm-svn: 168945
2012-11-30 05:49:15 +08:00
log->Printf ("Process::GetProfileData (buf = %p, size = %" PRIu64 ")", buf, (uint64_t)buf_size);
<rdar://problem/12720514> Sub-TLF: Provide service to profile the inferior This allows client to query profiling states on the inferior. llvm-svn: 168228
2012-11-17 08:21:04 +08:00
if (bytes_available > buf_size)
{
<rdar://problem/12780259> Prevent async and sync calls to get profile data from stomping on each other. At the same time, don't use '$' as end delimiter per chunk of profile data. llvm-svn: 168948
2012-11-30 06:14:45 +08:00
memcpy(buf, m_profile_data.front().data(), buf_size);
m_profile_data.front().erase(0, buf_size);
<rdar://problem/12720514> Sub-TLF: Provide service to profile the inferior This allows client to query profiling states on the inferior. llvm-svn: 168228
2012-11-17 08:21:04 +08:00
bytes_available = buf_size;
}
else
{
<rdar://problem/12780259> Prevent async and sync calls to get profile data from stomping on each other. At the same time, don't use '$' as end delimiter per chunk of profile data. llvm-svn: 168948
2012-11-30 06:14:45 +08:00
memcpy(buf, m_profile_data.front().data(), bytes_available);
m_profile_data.erase(m_profile_data.begin());
<rdar://problem/12720514> Sub-TLF: Provide service to profile the inferior This allows client to query profiling states on the inferior. llvm-svn: 168228
2012-11-17 08:21:04 +08:00
}
}
return bytes_available;
}
<rdar://problem/10103980> A long time ago we started to centralized the STDOUT in lldb_private::Process but we missed a few things still in ProcessGDBRemote. llvm-svn: 144491
2011-11-13 12:45:22 +08:00
//------------------------------------------------------------------
// 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)
{
<rdar://problem/13521159> LLDB is crashing when logging is enabled from lldb-perf-clang. This has to do with the global destructor chain as the process and its threads are being torn down. All logging channels now make one and only one instance that is kept in a global pointer which is never freed. This guarantees that logging can correctly continue as the process tears itself down. llvm-svn: 178191
2013-03-28 07:08:40 +08:00
Log *log (lldb_private::GetLogIfAllCategoriesSet (LIBLLDB_LOG_PROCESS));
<rdar://problem/10103980> A long time ago we started to centralized the STDOUT in lldb_private::Process but we missed a few things still in ProcessGDBRemote. llvm-svn: 144491
2011-11-13 12:45:22 +08:00
if (log)
Resolve printf formatting warnings on Linux: - use macros from inttypes.h for format strings instead of OS-specific types Patch from Matt Kopec! llvm-svn: 168945
2012-11-30 05:49:15 +08:00
log->Printf ("Process::GetSTDOUT (buf = %p, size = %" PRIu64 ")", buf, (uint64_t)buf_size);
<rdar://problem/10103980> A long time ago we started to centralized the STDOUT in lldb_private::Process but we missed a few things still in ProcessGDBRemote. llvm-svn: 144491
2011-11-13 12:45:22 +08:00
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)
{
<rdar://problem/13521159> LLDB is crashing when logging is enabled from lldb-perf-clang. This has to do with the global destructor chain as the process and its threads are being torn down. All logging channels now make one and only one instance that is kept in a global pointer which is never freed. This guarantees that logging can correctly continue as the process tears itself down. llvm-svn: 178191
2013-03-28 07:08:40 +08:00
Log *log (lldb_private::GetLogIfAllCategoriesSet (LIBLLDB_LOG_PROCESS));
<rdar://problem/10103980> A long time ago we started to centralized the STDOUT in lldb_private::Process but we missed a few things still in ProcessGDBRemote. llvm-svn: 144491
2011-11-13 12:45:22 +08:00
if (log)
Resolve printf formatting warnings on Linux: - use macros from inttypes.h for format strings instead of OS-specific types Patch from Matt Kopec! llvm-svn: 168945
2012-11-30 05:49:15 +08:00
log->Printf ("Process::GetSTDERR (buf = %p, size = %" PRIu64 ")", buf, (uint64_t)buf_size);
<rdar://problem/10103980> A long time ago we started to centralized the STDOUT in lldb_private::Process but we missed a few things still in ProcessGDBRemote. llvm-svn: 144491
2011-11-13 12:45:22 +08:00
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;
}
Make processes use InputReaders for their input. Move the process ReadThread stuff into the main Process class (out of the Process Plugins). This has the (intended) side effect of disabling the command line tool from reading input/commands while the process is running (the input is directed to the running process rather than to the command interpreter). llvm-svn: 119329
2010-11-16 13:07:41 +08:00
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);
}
size_t
Process::ProcessInputReaderCallback (void *baton,
InputReader &reader,
lldb::InputReaderAction notification,
const char *bytes,
size_t bytes_len)
{
Process *process = (Process *) baton;
switch (notification)
{
case eInputReaderActivate:
break;
case eInputReaderDeactivate:
break;
case eInputReaderReactivate:
break;
This patch captures and serializes all output being written by the command line driver, including the lldb prompt being output by editline, the asynchronous process output & error messages, and asynchronous messages written by target stop-hooks. As part of this it introduces a new Stream class, StreamAsynchronousIO. A StreamAsynchronousIO object is created with a broadcaster, who will eventually broadcast the stream's data for a listener to handle, and an event type indicating what type of event the broadcaster will broadcast. When the Write method is called on a StreamAsynchronousIO object, the data is appended to an internal string. When the Flush method is called on a StreamAsynchronousIO object, it broadcasts it's data string and clears the string. Anything in lldb-core that needs to generate asynchronous output for the end-user should use the StreamAsynchronousIO objects. I have also added a new notification type for InputReaders, to let them know that a asynchronous output has been written. This is to allow the input readers to, for example, refresh their prompts and lines, if desired. I added the case statements to all the input readers to catch this notification, but I haven't added any code for handling them yet (except to the IOChannel input reader). llvm-svn: 130721
2011-05-03 04:41:46 +08:00
case eInputReaderAsynchronousOutputWritten:
break;
Make processes use InputReaders for their input. Move the process ReadThread stuff into the main Process class (out of the Process Plugins). This has the (intended) side effect of disabling the command line tool from reading input/commands while the process is running (the input is directed to the running process rather than to the command interpreter). llvm-svn: 119329
2010-11-16 13:07:41 +08:00
case eInputReaderGotToken:
{
Error error;
process->PutSTDIN (bytes, bytes_len, error);
}
break;
Add the ability to catch and do the right thing with Interrupts (often control-c) and end-of-file (often control-d). llvm-svn: 119837
2010-11-20 04:47:54 +08:00
case eInputReaderInterrupt:
process->Halt ();
break;
case eInputReaderEndOfFile:
process->AppendSTDOUT ("^D", 2);
break;
Make processes use InputReaders for their input. Move the process ReadThread stuff into the main Process class (out of the Process Plugins). This has the (intended) side effect of disabling the command line tool from reading input/commands while the process is running (the input is directed to the running process rather than to the command interpreter). llvm-svn: 119329
2010-11-16 13:07:41 +08:00
case eInputReaderDone:
break;
}
return bytes_len;
}
void
Process::ResetProcessInputReader ()
{
m_process_input_reader.reset();
}
void
Use a pseudoterminal for local processes if no STDIO redirection or other file actions have been specified. llvm-svn: 144922
2011-11-18 06:14:31 +08:00
Process::SetSTDIOFileDescriptor (int file_descriptor)
Make processes use InputReaders for their input. Move the process ReadThread stuff into the main Process class (out of the Process Plugins). This has the (intended) side effect of disabling the command line tool from reading input/commands while the process is running (the input is directed to the running process rather than to the command interpreter). llvm-svn: 119329
2010-11-16 13:07:41 +08:00
{
// First set up the Read Thread for reading/handling process I/O
std::auto_ptr<ConnectionFileDescriptor> conn_ap (new ConnectionFileDescriptor (file_descriptor, 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 InputReader(m_target.GetDebugger()));
Error err (m_process_input_reader->Initialize (Process::ProcessInputReaderCallback,
this,
eInputReaderGranularityByte,
NULL,
NULL,
false));
if (err.Fail())
m_process_input_reader.reset();
}
}
}
}
void
Process::PushProcessInputReader ()
{
if (m_process_input_reader && !m_process_input_reader->IsActive())
m_target.GetDebugger().PushInputReader (m_process_input_reader);
}
void
Process::PopProcessInputReader ()
{
if (m_process_input_reader && m_process_input_reader->IsActive())
m_target.GetDebugger().PopInputReader (m_process_input_reader);
}
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
Cleaned up code that wasn't using the Initialize and Terminate paradigm by changing it to use it. There was an extra parameter added to the static accessor global user settings controllers that wasn't needed. A bool was being used as a parameter to the accessor just so it could be used to clean up the global user settings controller which is now fixed by splitting up the initialization into the "static void Class::Initialize()", access into the "static UserSettingsControllerSP & Class::GetSettingsController()", and cleanup into "static void Class::Terminate()". Also added initialize and terminate calls to the logging code to avoid issues when LLDB is shutting down. There were cases after the logging was switched over to use shared pointers where we could crash if the global destructor chain was being run and it causes the log to be destroyed and any any logging occurred. llvm-svn: 119757
2010-11-19 07:32:35 +08:00
void
The UserSettings controllers must be initialized & terminated in the correct order. Previously this was tacitly implemented but not enforced, so it was possible to accidentally do things in the wrong order and cause problems. This fixes that problem. llvm-svn: 127430
2011-03-11 06:14:10 +08:00
Process::SettingsInitialize ()
Cleaned up code that wasn't using the Initialize and Terminate paradigm by changing it to use it. There was an extra parameter added to the static accessor global user settings controllers that wasn't needed. A bool was being used as a parameter to the accessor just so it could be used to clean up the global user settings controller which is now fixed by splitting up the initialization into the "static void Class::Initialize()", access into the "static UserSettingsControllerSP & Class::GetSettingsController()", and cleanup into "static void Class::Terminate()". Also added initialize and terminate calls to the logging code to avoid issues when LLDB is shutting down. There were cases after the logging was switched over to use shared pointers where we could crash if the global destructor chain was being run and it causes the log to be destroyed and any any logging occurred. llvm-svn: 119757
2010-11-19 07:32:35 +08:00
{
Reimplemented the code that backed the "settings" in lldb. There were many issues with the previous implementation: - no setting auto completion - very manual and error prone way of getting/setting variables - tons of code duplication - useless instance names for processes, threads Now settings can easily be defined like option values. The new settings makes use of the "OptionValue" classes so we can re-use the option value code that we use to set settings in command options. No more instances, just "does the right thing". llvm-svn: 162366
2012-08-23 01:17:09 +08:00
// static std::vector<OptionEnumValueElement> g_plugins;
//
// int i=0;
// const char *name;
// OptionEnumValueElement option_enum;
// while ((name = PluginManager::GetProcessPluginNameAtIndex (i)) != NULL)
// {
// if (name)
// {
// option_enum.value = i;
// option_enum.string_value = name;
// option_enum.usage = PluginManager::GetProcessPluginDescriptionAtIndex (i);
// g_plugins.push_back (option_enum);
// }
// ++i;
// }
// option_enum.value = 0;
// option_enum.string_value = NULL;
// option_enum.usage = NULL;
// g_plugins.push_back (option_enum);
//
// for (i=0; (name = SettingsController::instance_settings_table[i].var_name); ++i)
// {
// if (::strcmp (name, "plugin") == 0)
// {
// SettingsController::instance_settings_table[i].enum_values = &g_plugins[0];
// break;
// }
// }
//
Remove further outdated "settings" code and also implement a few missing things. llvm-svn: 162376
2012-08-23 02:39:03 +08:00
Thread::SettingsInitialize ();
Cleaned up code that wasn't using the Initialize and Terminate paradigm by changing it to use it. There was an extra parameter added to the static accessor global user settings controllers that wasn't needed. A bool was being used as a parameter to the accessor just so it could be used to clean up the global user settings controller which is now fixed by splitting up the initialization into the "static void Class::Initialize()", access into the "static UserSettingsControllerSP & Class::GetSettingsController()", and cleanup into "static void Class::Terminate()". Also added initialize and terminate calls to the logging code to avoid issues when LLDB is shutting down. There were cases after the logging was switched over to use shared pointers where we could crash if the global destructor chain was being run and it causes the log to be destroyed and any any logging occurred. llvm-svn: 119757
2010-11-19 07:32:35 +08:00
}
This is a very large commit that completely re-does the way lldb handles user settable internal variables (the equivalent of set/show variables in gdb). In addition to the basic infrastructure (most of which is defined in UserSettingsController.{h,cpp}, there are examples of two classes that have been set up to contain user settable variables (the Debugger and Process classes). The 'settings' command has been modified to be a command-subcommand structure, and the 'set', 'show' and 'append' commands have been moved into this sub-commabnd structure. The old StateVariable class has been completely replaced by this, and the state variable dictionary has been removed from the Command Interpreter. Places that formerly accessed the state variable mechanism have been modified to access the variables in this new structure instead (checking the term-width; getting/checking the prompt; etc.) Variables are attached to classes; there are two basic "flavors" of variables that can be set: "global" variables (static/class-wide), and "instance" variables (one per instance of the class). The whole thing has been set up so that any global or instance variable can be set at any time (e.g. on start up, in your .lldbinit file), whether or not any instances actually exist (there's a whole pending and default values mechanism to help deal with that). llvm-svn: 113041
2010-09-04 08:03:46 +08:00
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
The UserSettings controllers must be initialized & terminated in the correct order. Previously this was tacitly implemented but not enforced, so it was possible to accidentally do things in the wrong order and cause problems. This fixes that problem. llvm-svn: 127430
2011-03-11 06:14:10 +08:00
Process::SettingsTerminate ()
Cleaned up code that wasn't using the Initialize and Terminate paradigm by changing it to use it. There was an extra parameter added to the static accessor global user settings controllers that wasn't needed. A bool was being used as a parameter to the accessor just so it could be used to clean up the global user settings controller which is now fixed by splitting up the initialization into the "static void Class::Initialize()", access into the "static UserSettingsControllerSP & Class::GetSettingsController()", and cleanup into "static void Class::Terminate()". Also added initialize and terminate calls to the logging code to avoid issues when LLDB is shutting down. There were cases after the logging was switched over to use shared pointers where we could crash if the global destructor chain was being run and it causes the log to be destroyed and any any logging occurred. llvm-svn: 119757
2010-11-19 07:32:35 +08:00
{
Remove further outdated "settings" code and also implement a few missing things. llvm-svn: 162376
2012-08-23 02:39:03 +08:00
Thread::SettingsTerminate ();
This is a very large commit that completely re-does the way lldb handles user settable internal variables (the equivalent of set/show variables in gdb). In addition to the basic infrastructure (most of which is defined in UserSettingsController.{h,cpp}, there are examples of two classes that have been set up to contain user settable variables (the Debugger and Process classes). The 'settings' command has been modified to be a command-subcommand structure, and the 'set', 'show' and 'append' commands have been moved into this sub-commabnd structure. The old StateVariable class has been completely replaced by this, and the state variable dictionary has been removed from the Command Interpreter. Places that formerly accessed the state variable mechanism have been modified to access the variables in this new structure instead (checking the term-width; getting/checking the prompt; etc.) Variables are attached to classes; there are two basic "flavors" of variables that can be set: "global" variables (static/class-wide), and "instance" variables (one per instance of the class). The whole thing has been set up so that any global or instance variable can be set at any time (e.g. on start up, in your .lldbinit file), whether or not any instances actually exist (there's a whole pending and default values mechanism to help deal with that). llvm-svn: 113041
2010-09-04 08:03:46 +08:00
}
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
Moved the code in ClangUserExpression that set up & ran the thread plan with timeouts, and restarting with all threads into a utility function in Process. This required a bunch of renaming. Added a ThreadPlanCallUserExpression that differs from ThreadPlanCallFunction in that it holds onto a shared pointer to its ClangUserExpression so that can't go away before the thread plan is done using it. Fixed the stop message when you hit a breakpoint while running a user expression so it is more obvious what has happened. llvm-svn: 120386
2010-11-30 10:22:11 +08:00
Process::RunThreadPlan (ExecutionContext &exe_ctx,
We sometimes need to be able to call functions (via Process::RunThreadPlan) from code run on the private state thread. To do that we have to spin up a temporary "private state thread" that will respond to events from the lower level process plugins. This check-in should work to do that, but it is still buggy. However, if you don't call functions on the private state thread, these changes make no difference. This patch also moves the code in the AppleObjCRuntime step-through-trampoline handler that might call functions (in the case where the debug server doesn't support the memory allocate/deallocate packet) out to a safe place to do that call. llvm-svn: 154230
2012-04-07 08:00:41 +08:00
lldb::ThreadPlanSP &thread_plan_sp,
Moved the code in ClangUserExpression that set up & ran the thread plan with timeouts, and restarting with all threads into a utility function in Process. This required a bunch of renaming. Added a ThreadPlanCallUserExpression that differs from ThreadPlanCallFunction in that it holds onto a shared pointer to its ClangUserExpression so that can't go away before the thread plan is done using it. Fixed the stop message when you hit a breakpoint while running a user expression so it is more obvious what has happened. llvm-svn: 120386
2010-11-30 10:22:11 +08:00
bool stop_others,
Add the ability to set timeout & "run all threads" options both from the "expr" command and from the SB API's that evaluate expressions. <rdar://problem/12457211> llvm-svn: 166062
2012-10-17 05:41:58 +08:00
bool run_others,
Separated the "expr --unwind-on-error" behavior into two parts, actual errors (i.e. crashes) which continue to be controlled by the --unwind-on-error flag, and --ignore-breakpoint which separately controls behavior when a called function hits a breakpoint. For breakpoints, we don't unwind, we either stop, or ignore the breakpoint, which makes more sense. Also make both these behaviors globally settable through "settings set". Also handle the case where a breakpoint command calls code that ends up re-hitting the breakpoint. We were recursing and crashing. Now we just stop without calling the second command. <rdar://problem/12986644> <rdar://problem/9119325> llvm-svn: 172503
2013-01-15 10:47:48 +08:00
bool unwind_on_error,
bool ignore_breakpoints,
Add the ability to set timeout & "run all threads" options both from the "expr" command and from the SB API's that evaluate expressions. <rdar://problem/12457211> llvm-svn: 166062
2012-10-17 05:41:58 +08:00
uint32_t timeout_usec,
Moved the code in ClangUserExpression that set up & ran the thread plan with timeouts, and restarting with all threads into a utility function in Process. This required a bunch of renaming. Added a ThreadPlanCallUserExpression that differs from ThreadPlanCallFunction in that it holds onto a shared pointer to its ClangUserExpression so that can't go away before the thread plan is done using it. Fixed the stop message when you hit a breakpoint while running a user expression so it is more obvious what has happened. llvm-svn: 120386
2010-11-30 10:22:11 +08:00
Stream &errors)
{
ExecutionResults return_value = eExecutionSetupError;
Back up both the register AND the stop state when calling functions. Set the thread state to "bland" before calling functions so they don't inherit the pending signals and die. llvm-svn: 123869
2011-01-20 10:03:18 +08:00
if (thread_plan_sp.get() == NULL)
{
errors.Printf("RunThreadPlan called with empty thread plan.");
Fixed the LLDB build so that we can have private types, private enums and public types and public enums. This was done to keep the SWIG stuff from parsing all sorts of enums and types that weren't needed, and allows us to abstract our API better. llvm-svn: 128239
2011-03-25 05:19:54 +08:00
return eExecutionSetupError;
Back up both the register AND the stop state when calling functions. Set the thread state to "bland" before calling functions so they don't inherit the pending signals and die. llvm-svn: 123869
2011-01-20 10:03:18 +08:00
}
RunThreadPlan should make sure the plan passed in is valid before running it. <rdar://problem/13485541> llvm-svn: 178202
2013-03-28 08:05:34 +08:00
if (!thread_plan_sp->ValidatePlan(NULL))
{
errors.Printf ("RunThreadPlan called with an invalid thread plan.");
return eExecutionSetupError;
}
Converted the lldb_private::Process over to use the intrusive shared pointers. Changed the ExecutionContext over to use shared pointers for the target, process, thread and frame since these objects can easily go away at any time and any object that was holding onto an ExecutionContext was running the risk of using a bad object. Now that the shared pointers for target, process, thread and frame are just a single pointer (they all use the instrusive shared pointers) the execution context is much safer and still the same size. Made the shared pointers in the the ExecutionContext class protected and made accessors for all of the various ways to get at the pointers, references, and shared pointers. llvm-svn: 140298
2011-09-22 12:58:26 +08:00
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;
}
Back up both the register AND the stop state when calling functions. Set the thread state to "bland" before calling functions so they don't inherit the pending signals and die. llvm-svn: 123869
2011-01-20 10:03:18 +08:00
RunThreadPlan should set the plan to "not private" since it needs that, and then reset it to the original value when done. llvm-svn: 131498
2011-05-18 06:24:54 +08:00
// 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);
More useful STEP logging. Be sure to clear out the base plan's m_report_run and m_report_stop each time we resume so we don't use stale values. llvm-svn: 124113
2011-01-24 14:34:17 +08:00
if (m_private_state.GetValue() != eStateStopped)
{
errors.Printf ("RunThreadPlan called while the private state was not stopped.");
Fixed the LLDB build so that we can have private types, private enums and public types and public enums. This was done to keep the SWIG stuff from parsing all sorts of enums and types that weren't needed, and allows us to abstract our API better. llvm-svn: 128239
2011-03-25 05:19:54 +08:00
return eExecutionSetupError;
More useful STEP logging. Be sure to clear out the base plan's m_report_run and m_report_stop each time we resume so we don't use stale values. llvm-svn: 124113
2011-01-24 14:34:17 +08:00
}
Remember to restore the frame in the exe_ctx passed in to RunThreadPlan. Also, default "source_init_file" to False in the version of SBDebugger::Create so that we don't pick up the init file in Python. llvm-svn: 137545
2011-08-13 08:56:10 +08:00
// Save the thread & frame from the exe_ctx for restoration after we run
Converted the lldb_private::Process over to use the intrusive shared pointers. Changed the ExecutionContext over to use shared pointers for the target, process, thread and frame since these objects can easily go away at any time and any object that was holding onto an ExecutionContext was running the risk of using a bad object. Now that the shared pointers for target, process, thread and frame are just a single pointer (they all use the instrusive shared pointers) the execution context is much safer and still the same size. Made the shared pointers in the the ExecutionContext class protected and made accessors for all of the various ways to get at the pointers, references, and shared pointers. llvm-svn: 140298
2011-09-22 12:58:26 +08:00
const uint32_t thread_idx_id = thread->GetIndexID();
If RunThreadPlan is called on a thread that doesn't have a selected frame, select frame 0. <rdar://problem/13093321> llvm-svn: 175573
2013-02-20 07:22:45 +08:00
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();
Moved the code in ClangUserExpression that set up & ran the thread plan with timeouts, and restarting with all threads into a utility function in Process. This required a bunch of renaming. Added a ThreadPlanCallUserExpression that differs from ThreadPlanCallFunction in that it holds onto a shared pointer to its ClangUserExpression so that can't go away before the thread plan is done using it. Fixed the stop message when you hit a breakpoint while running a user expression so it is more obvious what has happened. llvm-svn: 120386
2010-11-30 10:22:11 +08:00
// 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.
Converted the lldb_private::Process over to use the intrusive shared pointers. Changed the ExecutionContext over to use shared pointers for the target, process, thread and frame since these objects can easily go away at any time and any object that was holding onto an ExecutionContext was running the risk of using a bad object. Now that the shared pointers for target, process, thread and frame are just a single pointer (they all use the instrusive shared pointers) the execution context is much safer and still the same size. Made the shared pointers in the the ExecutionContext class protected and made accessors for all of the various ways to get at the pointers, references, and shared pointers. llvm-svn: 140298
2011-09-22 12:58:26 +08:00
lldb::ThreadSP selected_thread_sp = GetThreadList().GetSelectedThread();
Moved the code in ClangUserExpression that set up & ran the thread plan with timeouts, and restarting with all threads into a utility function in Process. This required a bunch of renaming. Added a ThreadPlanCallUserExpression that differs from ThreadPlanCallFunction in that it holds onto a shared pointer to its ClangUserExpression so that can't go away before the thread plan is done using it. Fixed the stop message when you hit a breakpoint while running a user expression so it is more obvious what has happened. llvm-svn: 120386
2010-11-30 10:22:11 +08:00
Remember to restore the frame in the exe_ctx passed in to RunThreadPlan. Also, default "source_init_file" to False in the version of SBDebugger::Create so that we don't pick up the init file in Python. llvm-svn: 137545
2011-08-13 08:56:10 +08:00
uint32_t selected_tid;
StackID selected_stack_id;
Don't put modules for .o files into the global shared module list. We used to do this because we needed to find the shared pointer for a .o file when the .o file's module was needed in a SymbolContext since the module in a symbol context was a shared pointer. Now that we are using intrusive pointers we don't have this limitation anymore since any instrusive shared pointer can be made from a pointer to an object all on its own. Also switched over to having the Module and SymbolVendor use shared pointers to their object files as had a leak on MacOSX when the SymbolVendor's object file wasn't the same as the Module's (debug info in a stand along file (dSYM file)). Now everything will correctly clean itself up when the module goes away after an executable gets rebuilt. Now we correctly get rid of .o files that are used with the DWARF with debug map executables on subsequent runs since the only shared pointer to the object files in from the DWARF symbol file debug map parser, and when the module gets replaced, it destroys to old one along with all .o files. Also added a small optimization when using BSD archives where we will remove old BSD containers from the shared list when they are outdated. llvm-svn: 140002
2011-09-19 02:59:15 +08:00
if (selected_thread_sp)
Moved the code in ClangUserExpression that set up & ran the thread plan with timeouts, and restarting with all threads into a utility function in Process. This required a bunch of renaming. Added a ThreadPlanCallUserExpression that differs from ThreadPlanCallFunction in that it holds onto a shared pointer to its ClangUserExpression so that can't go away before the thread plan is done using it. Fixed the stop message when you hit a breakpoint while running a user expression so it is more obvious what has happened. llvm-svn: 120386
2010-11-30 10:22:11 +08:00
{
selected_tid = selected_thread_sp->GetIndexID();
Remember to restore the frame in the exe_ctx passed in to RunThreadPlan. Also, default "source_init_file" to False in the version of SBDebugger::Create so that we don't pick up the init file in Python. llvm-svn: 137545
2011-08-13 08:56:10 +08:00
selected_stack_id = selected_thread_sp->GetSelectedFrame()->GetStackID();
Moved the code in ClangUserExpression that set up & ran the thread plan with timeouts, and restarting with all threads into a utility function in Process. This required a bunch of renaming. Added a ThreadPlanCallUserExpression that differs from ThreadPlanCallFunction in that it holds onto a shared pointer to its ClangUserExpression so that can't go away before the thread plan is done using it. Fixed the stop message when you hit a breakpoint while running a user expression so it is more obvious what has happened. llvm-svn: 120386
2010-11-30 10:22:11 +08:00
}
else
{
selected_tid = LLDB_INVALID_THREAD_ID;
}
We sometimes need to be able to call functions (via Process::RunThreadPlan) from code run on the private state thread. To do that we have to spin up a temporary "private state thread" that will respond to events from the lower level process plugins. This check-in should work to do that, but it is still buggy. However, if you don't call functions on the private state thread, these changes make no difference. This patch also moves the code in the AppleObjCRuntime step-through-trampoline handler that might call functions (in the case where the debug server doesn't support the memory allocate/deallocate packet) out to a safe place to do that call. llvm-svn: 154230
2012-04-07 08:00:41 +08:00
lldb::thread_t backup_private_state_thread = LLDB_INVALID_HOST_THREAD;
Two changes, 1) Start the PrivateStateThread stopped, and then in StartPrivateStateThread, make the private state thread and then resume it before we say the thread is created. That way we know it is listening for events by the time we get out of StartPrivateStateThread. 2) Backstop running a thread plan when calling Process::RunThreadPlan on the private state thread with a ThreadPlanBase so that running the plan doesn't pass its stop events to whatever plans happen to be above us on the thread plan stack. llvm-svn: 154368
2012-04-10 09:21:57 +08:00
lldb::StateType old_state;
lldb::ThreadPlanSP stopper_base_plan_sp;
We sometimes need to be able to call functions (via Process::RunThreadPlan) from code run on the private state thread. To do that we have to spin up a temporary "private state thread" that will respond to events from the lower level process plugins. This check-in should work to do that, but it is still buggy. However, if you don't call functions on the private state thread, these changes make no difference. This patch also moves the code in the AppleObjCRuntime step-through-trampoline handler that might call functions (in the case where the debug server doesn't support the memory allocate/deallocate packet) out to a safe place to do that call. llvm-svn: 154230
2012-04-07 08:00:41 +08:00
<rdar://problem/13521159> LLDB is crashing when logging is enabled from lldb-perf-clang. This has to do with the global destructor chain as the process and its threads are being torn down. All logging channels now make one and only one instance that is kept in a global pointer which is never freed. This guarantees that logging can correctly continue as the process tears itself down. llvm-svn: 178191
2013-03-28 07:08:40 +08:00
Log *log(lldb_private::GetLogIfAnyCategoriesSet (LIBLLDB_LOG_STEP | LIBLLDB_LOG_PROCESS));
We sometimes need to be able to call functions (via Process::RunThreadPlan) from code run on the private state thread. To do that we have to spin up a temporary "private state thread" that will respond to events from the lower level process plugins. This check-in should work to do that, but it is still buggy. However, if you don't call functions on the private state thread, these changes make no difference. This patch also moves the code in the AppleObjCRuntime step-through-trampoline handler that might call functions (in the case where the debug server doesn't support the memory allocate/deallocate packet) out to a safe place to do that call. llvm-svn: 154230
2012-04-07 08:00:41 +08:00
if (Host::GetCurrentThread() == m_private_state_thread)
{
Two changes, 1) Start the PrivateStateThread stopped, and then in StartPrivateStateThread, make the private state thread and then resume it before we say the thread is created. That way we know it is listening for events by the time we get out of StartPrivateStateThread. 2) Backstop running a thread plan when calling Process::RunThreadPlan on the private state thread with a ThreadPlanBase so that running the plan doesn't pass its stop events to whatever plans happen to be above us on the thread plan stack. llvm-svn: 154368
2012-04-10 09:21:57 +08:00
// 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.
We sometimes need to be able to call functions (via Process::RunThreadPlan) from code run on the private state thread. To do that we have to spin up a temporary "private state thread" that will respond to events from the lower level process plugins. This check-in should work to do that, but it is still buggy. However, if you don't call functions on the private state thread, these changes make no difference. This patch also moves the code in the AppleObjCRuntime step-through-trampoline handler that might call functions (in the case where the debug server doesn't support the memory allocate/deallocate packet) out to a safe place to do that call. llvm-svn: 154230
2012-04-07 08:00:41 +08:00
// The simplest thing to do is to spin up a temporary thread to handle private state thread events while
Two changes, 1) Start the PrivateStateThread stopped, and then in StartPrivateStateThread, make the private state thread and then resume it before we say the thread is created. That way we know it is listening for events by the time we get out of StartPrivateStateThread. 2) Backstop running a thread plan when calling Process::RunThreadPlan on the private state thread with a ThreadPlanBase so that running the plan doesn't pass its stop events to whatever plans happen to be above us on the thread plan stack. llvm-svn: 154368
2012-04-10 09:21:57 +08:00
// we are fielding public events here.
if (log)
Han Ming's commit in r168228 had a bunch of 4-space tabs in the source files. Expand to spaces. No content changes, just whitespace. llvm-svn: 168238
2012-11-17 09:41:04 +08:00
log->Printf ("Running thread plan on private state thread, spinning up another state thread to handle the events.");
Two changes, 1) Start the PrivateStateThread stopped, and then in StartPrivateStateThread, make the private state thread and then resume it before we say the thread is created. That way we know it is listening for events by the time we get out of StartPrivateStateThread. 2) Backstop running a thread plan when calling Process::RunThreadPlan on the private state thread with a ThreadPlanBase so that running the plan doesn't pass its stop events to whatever plans happen to be above us on the thread plan stack. llvm-svn: 154368
2012-04-10 09:21:57 +08:00
We sometimes need to be able to call functions (via Process::RunThreadPlan) from code run on the private state thread. To do that we have to spin up a temporary "private state thread" that will respond to events from the lower level process plugins. This check-in should work to do that, but it is still buggy. However, if you don't call functions on the private state thread, these changes make no difference. This patch also moves the code in the AppleObjCRuntime step-through-trampoline handler that might call functions (in the case where the debug server doesn't support the memory allocate/deallocate packet) out to a safe place to do that call. llvm-svn: 154230
2012-04-07 08:00:41 +08:00
backup_private_state_thread = m_private_state_thread;
Two changes, 1) Start the PrivateStateThread stopped, and then in StartPrivateStateThread, make the private state thread and then resume it before we say the thread is created. That way we know it is listening for events by the time we get out of StartPrivateStateThread. 2) Backstop running a thread plan when calling Process::RunThreadPlan on the private state thread with a ThreadPlanBase so that running the plan doesn't pass its stop events to whatever plans happen to be above us on the thread plan stack. llvm-svn: 154368
2012-04-10 09:21:57 +08:00
// 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:
We sometimes need to be able to call functions (via Process::RunThreadPlan) from code run on the private state thread. To do that we have to spin up a temporary "private state thread" that will respond to events from the lower level process plugins. This check-in should work to do that, but it is still buggy. However, if you don't call functions on the private state thread, these changes make no difference. This patch also moves the code in the AppleObjCRuntime step-through-trampoline handler that might call functions (in the case where the debug server doesn't support the memory allocate/deallocate packet) out to a safe place to do that call. llvm-svn: 154230
2012-04-07 08:00:41 +08:00
StartPrivateStateThread(true);
}
thread->QueueThreadPlan(thread_plan_sp, false); // This used to pass "true" does that make sense?
Moved the code in ClangUserExpression that set up & ran the thread plan with timeouts, and restarting with all threads into a utility function in Process. This required a bunch of renaming. Added a ThreadPlanCallUserExpression that differs from ThreadPlanCallFunction in that it holds onto a shared pointer to its ClangUserExpression so that can't go away before the thread plan is done using it. Fixed the stop message when you hit a breakpoint while running a user expression so it is more obvious what has happened. llvm-svn: 120386
2010-11-30 10:22:11 +08:00
Add some more logging of broadcaster and Process. Also, protect the event broadcasting against hijacking in mid-event delivery. llvm-svn: 124084
2011-01-24 05:14:08 +08:00
Listener listener("lldb.process.listener.run-thread-plan");
Rework the RunThreadPlan event handling to use Event Hijacking not stopping the event thread. Also clarify the logic of the function. llvm-svn: 125083
2011-02-08 13:20:59 +08:00
Fixed a bug that caused the Process not to rebroadcast the fact that a process exited while running a thread plan. For example, if a user types the expression expr (void)exit(0) then the process terminates but LLDB does not notify listeners like Xcode that this occurred. <rdar://problem/11845155> llvm-svn: 160077
2012-07-12 05:31:24 +08:00
lldb::EventSP event_to_broadcast_sp;
Rework the RunThreadPlan event handling to use Event Hijacking not stopping the event thread. Also clarify the logic of the function. llvm-svn: 125083
2011-02-08 13:20:59 +08:00
Moved the code in ClangUserExpression that set up & ran the thread plan with timeouts, and restarting with all threads into a utility function in Process. This required a bunch of renaming. Added a ThreadPlanCallUserExpression that differs from ThreadPlanCallFunction in that it holds onto a shared pointer to its ClangUserExpression so that can't go away before the thread plan is done using it. Fixed the stop message when you hit a breakpoint while running a user expression so it is more obvious what has happened. llvm-svn: 120386
2010-11-30 10:22:11 +08:00
{
Fixed a bug that caused the Process not to rebroadcast the fact that a process exited while running a thread plan. For example, if a user types the expression expr (void)exit(0) then the process terminates but LLDB does not notify listeners like Xcode that this occurred. <rdar://problem/11845155> llvm-svn: 160077
2012-07-12 05:31:24 +08:00
// 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.
Rework the RunThreadPlan event handling to use Event Hijacking not stopping the event thread. Also clarify the logic of the function. llvm-svn: 125083
2011-02-08 13:20:59 +08:00
Fixed a bug that caused the Process not to rebroadcast the fact that a process exited while running a thread plan. For example, if a user types the expression expr (void)exit(0) then the process terminates but LLDB does not notify listeners like Xcode that this occurred. <rdar://problem/11845155> llvm-svn: 160077
2012-07-12 05:31:24 +08:00
ProcessEventHijacker run_thread_plan_hijacker (*this, &listener);
if (log)
Rework the RunThreadPlan event handling to use Event Hijacking not stopping the event thread. Also clarify the logic of the function. llvm-svn: 125083
2011-02-08 13:20:59 +08:00
{
Fixed a bug that caused the Process not to rebroadcast the fact that a process exited while running a thread plan. For example, if a user types the expression expr (void)exit(0) then the process terminates but LLDB does not notify listeners like Xcode that this occurred. <rdar://problem/11845155> llvm-svn: 160077
2012-07-12 05:31:24 +08:00
StreamString s;
thread_plan_sp->GetDescription(&s, lldb::eDescriptionLevelVerbose);
Resolve printf formatting warnings on Linux: - use macros from inttypes.h for format strings instead of OS-specific types Patch from Matt Kopec! llvm-svn: 168945
2012-11-30 05:49:15 +08:00
log->Printf ("Process::RunThreadPlan(): Resuming thread %u - 0x%4.4" PRIx64 " to run thread plan \"%s\".",
Fixed a bug that caused the Process not to rebroadcast the fact that a process exited while running a thread plan. For example, if a user types the expression expr (void)exit(0) then the process terminates but LLDB does not notify listeners like Xcode that this occurred. <rdar://problem/11845155> llvm-svn: 160077
2012-07-12 05:31:24 +08:00
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;
Reworked the way Process::RunThreadPlan and the ThreadPlanCallFunction interoperate to fix problems where hitting auto-continue signals while running a thread plan would cause us to lose control of the debug session. <rdar://problem/12993641> llvm-svn: 174793
2013-02-09 09:29:05 +08:00
bool before_first_timeout = true; // This is set to false the first time that we have to halt the target.
Fixed a bug that caused the Process not to rebroadcast the fact that a process exited while running a thread plan. For example, if a user types the expression expr (void)exit(0) then the process terminates but LLDB does not notify listeners like Xcode that this occurred. <rdar://problem/11845155> llvm-svn: 160077
2012-07-12 05:31:24 +08:00
bool do_resume = true;
Separated the "expr --unwind-on-error" behavior into two parts, actual errors (i.e. crashes) which continue to be controlled by the --unwind-on-error flag, and --ignore-breakpoint which separately controls behavior when a called function hits a breakpoint. For breakpoints, we don't unwind, we either stop, or ignore the breakpoint, which makes more sense. Also make both these behaviors globally settable through "settings set". Also handle the case where a breakpoint command calls code that ends up re-hitting the breakpoint. We were recursing and crashing. Now we just stop without calling the second command. <rdar://problem/12986644> <rdar://problem/9119325> llvm-svn: 172503
2013-01-15 10:47:48 +08:00
bool handle_running_event = true;
Add the ability to set timeout & "run all threads" options both from the "expr" command and from the SB API's that evaluate expressions. <rdar://problem/12457211> llvm-svn: 166062
2012-10-17 05:41:58 +08:00
const uint64_t default_one_thread_timeout_usec = 250000;
Fixed a bug that caused the Process not to rebroadcast the fact that a process exited while running a thread plan. For example, if a user types the expression expr (void)exit(0) then the process terminates but LLDB does not notify listeners like Xcode that this occurred. <rdar://problem/11845155> llvm-svn: 160077
2012-07-12 05:31:24 +08:00
Reworked the way Process::RunThreadPlan and the ThreadPlanCallFunction interoperate to fix problems where hitting auto-continue signals while running a thread plan would cause us to lose control of the debug session. <rdar://problem/12993641> llvm-svn: 174793
2013-02-09 09:29:05 +08:00
// This is just for accounting:
uint32_t num_resumes = 0;
TimeValue one_thread_timeout = TimeValue::Now();
TimeValue final_timeout = one_thread_timeout;
if (run_others)
{
// If we are running all threads then we take half the time to run all threads, bounded by
// .25 sec.
if (timeout_usec == 0)
one_thread_timeout.OffsetWithMicroSeconds(default_one_thread_timeout_usec);
else
{
uint64_t computed_timeout = computed_timeout = timeout_usec / 2;
if (computed_timeout > default_one_thread_timeout_usec)
computed_timeout = default_one_thread_timeout_usec;
one_thread_timeout.OffsetWithMicroSeconds(computed_timeout);
}
final_timeout.OffsetWithMicroSeconds (timeout_usec);
}
else
{
if (timeout_usec != 0)
final_timeout.OffsetWithMicroSeconds(timeout_usec);
}
The Function calling thread plan was replacing the stored stop info too soon, causing recursive entry into the breakpoint StopInfo's PerformAction, which is bad. Reworked this so that it is now correct. <rdar://problem/12501259> llvm-svn: 168634
2012-11-27 07:52:18 +08:00
// 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.
Fixed a bug that caused the Process not to rebroadcast the fact that a process exited while running a thread plan. For example, if a user types the expression expr (void)exit(0) then the process terminates but LLDB does not notify listeners like Xcode that this occurred. <rdar://problem/11845155> llvm-svn: 160077
2012-07-12 05:31:24 +08:00
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.
Reworked the way Process::RunThreadPlan and the ThreadPlanCallFunction interoperate to fix problems where hitting auto-continue signals while running a thread plan would cause us to lose control of the debug session. <rdar://problem/12993641> llvm-svn: 174793
2013-02-09 09:29:05 +08:00
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);
Rework the RunThreadPlan event handling to use Event Hijacking not stopping the event thread. Also clarify the logic of the function. llvm-svn: 125083
2011-02-08 13:20:59 +08:00
Separated the "expr --unwind-on-error" behavior into two parts, actual errors (i.e. crashes) which continue to be controlled by the --unwind-on-error flag, and --ignore-breakpoint which separately controls behavior when a called function hits a breakpoint. For breakpoints, we don't unwind, we either stop, or ignore the breakpoint, which makes more sense. Also make both these behaviors globally settable through "settings set". Also handle the case where a breakpoint command calls code that ends up re-hitting the breakpoint. We were recursing and crashing. Now we just stop without calling the second command. <rdar://problem/12986644> <rdar://problem/9119325> llvm-svn: 172503
2013-01-15 10:47:48 +08:00
if (do_resume || handle_running_event)
Rework the RunThreadPlan event handling to use Event Hijacking not stopping the event thread. Also clarify the logic of the function. llvm-svn: 125083
2011-02-08 13:20:59 +08:00
{
Fixed a bug that caused the Process not to rebroadcast the fact that a process exited while running a thread plan. For example, if a user types the expression expr (void)exit(0) then the process terminates but LLDB does not notify listeners like Xcode that this occurred. <rdar://problem/11845155> llvm-svn: 160077
2012-07-12 05:31:24 +08:00
// Do the initial resume and wait for the running event before going further.
Separated the "expr --unwind-on-error" behavior into two parts, actual errors (i.e. crashes) which continue to be controlled by the --unwind-on-error flag, and --ignore-breakpoint which separately controls behavior when a called function hits a breakpoint. For breakpoints, we don't unwind, we either stop, or ignore the breakpoint, which makes more sense. Also make both these behaviors globally settable through "settings set". Also handle the case where a breakpoint command calls code that ends up re-hitting the breakpoint. We were recursing and crashing. Now we just stop without calling the second command. <rdar://problem/12986644> <rdar://problem/9119325> llvm-svn: 172503
2013-01-15 10:47:48 +08:00
if (do_resume)
Fixed a bug that caused the Process not to rebroadcast the fact that a process exited while running a thread plan. For example, if a user types the expression expr (void)exit(0) then the process terminates but LLDB does not notify listeners like Xcode that this occurred. <rdar://problem/11845155> llvm-svn: 160077
2012-07-12 05:31:24 +08:00
{
Reworked the way Process::RunThreadPlan and the ThreadPlanCallFunction interoperate to fix problems where hitting auto-continue signals while running a thread plan would cause us to lose control of the debug session. <rdar://problem/12993641> llvm-svn: 174793
2013-02-09 09:29:05 +08:00
num_resumes++;
Separated the "expr --unwind-on-error" behavior into two parts, actual errors (i.e. crashes) which continue to be controlled by the --unwind-on-error flag, and --ignore-breakpoint which separately controls behavior when a called function hits a breakpoint. For breakpoints, we don't unwind, we either stop, or ignore the breakpoint, which makes more sense. Also make both these behaviors globally settable through "settings set". Also handle the case where a breakpoint command calls code that ends up re-hitting the breakpoint. We were recursing and crashing. Now we just stop without calling the second command. <rdar://problem/12986644> <rdar://problem/9119325> llvm-svn: 172503
2013-01-15 10:47:48 +08:00
Error resume_error = PrivateResume ();
if (!resume_error.Success())
{
Reworked the way Process::RunThreadPlan and the ThreadPlanCallFunction interoperate to fix problems where hitting auto-continue signals while running a thread plan would cause us to lose control of the debug session. <rdar://problem/12993641> llvm-svn: 174793
2013-02-09 09:29:05 +08:00
errors.Printf("Error resuming inferior the %d time: \"%s\".\n",
num_resumes,
resume_error.AsCString());
Separated the "expr --unwind-on-error" behavior into two parts, actual errors (i.e. crashes) which continue to be controlled by the --unwind-on-error flag, and --ignore-breakpoint which separately controls behavior when a called function hits a breakpoint. For breakpoints, we don't unwind, we either stop, or ignore the breakpoint, which makes more sense. Also make both these behaviors globally settable through "settings set". Also handle the case where a breakpoint command calls code that ends up re-hitting the breakpoint. We were recursing and crashing. Now we just stop without calling the second command. <rdar://problem/12986644> <rdar://problem/9119325> llvm-svn: 172503
2013-01-15 10:47:48 +08:00
return_value = eExecutionSetupError;
break;
}
Fixed a bug that caused the Process not to rebroadcast the fact that a process exited while running a thread plan. For example, if a user types the expression expr (void)exit(0) then the process terminates but LLDB does not notify listeners like Xcode that this occurred. <rdar://problem/11845155> llvm-svn: 160077
2012-07-12 05:31:24 +08:00
}
Reworked the way Process::RunThreadPlan and the ThreadPlanCallFunction interoperate to fix problems where hitting auto-continue signals while running a thread plan would cause us to lose control of the debug session. <rdar://problem/12993641> llvm-svn: 174793
2013-02-09 09:29:05 +08:00
TimeValue resume_timeout = TimeValue::Now();
resume_timeout.OffsetWithMicroSeconds(500000);
got_event = listener.WaitForEvent(&resume_timeout, event_sp);
Fixed a bug that caused the Process not to rebroadcast the fact that a process exited while running a thread plan. For example, if a user types the expression expr (void)exit(0) then the process terminates but LLDB does not notify listeners like Xcode that this occurred. <rdar://problem/11845155> llvm-svn: 160077
2012-07-12 05:31:24 +08:00
if (!got_event)
{
if (log)
Reworked the way Process::RunThreadPlan and the ThreadPlanCallFunction interoperate to fix problems where hitting auto-continue signals while running a thread plan would cause us to lose control of the debug session. <rdar://problem/12993641> llvm-svn: 174793
2013-02-09 09:29:05 +08:00
log->Printf ("Process::RunThreadPlan(): didn't get any event after resume %d, exiting.",
num_resumes);
Rework the RunThreadPlan event handling to use Event Hijacking not stopping the event thread. Also clarify the logic of the function. llvm-svn: 125083
2011-02-08 13:20:59 +08:00
Reworked the way Process::RunThreadPlan and the ThreadPlanCallFunction interoperate to fix problems where hitting auto-continue signals while running a thread plan would cause us to lose control of the debug session. <rdar://problem/12993641> llvm-svn: 174793
2013-02-09 09:29:05 +08:00
errors.Printf("Didn't get any event after resume %d, exiting.", num_resumes);
Fixed a bug that caused the Process not to rebroadcast the fact that a process exited while running a thread plan. For example, if a user types the expression expr (void)exit(0) then the process terminates but LLDB does not notify listeners like Xcode that this occurred. <rdar://problem/11845155> llvm-svn: 160077
2012-07-12 05:31:24 +08:00
return_value = eExecutionSetupError;
break;
}
stop_state = Process::ProcessEventData::GetStateFromEvent(event_sp.get());
Reworked the way Process::RunThreadPlan and the ThreadPlanCallFunction interoperate to fix problems where hitting auto-continue signals while running a thread plan would cause us to lose control of the debug session. <rdar://problem/12993641> llvm-svn: 174793
2013-02-09 09:29:05 +08:00
Fixed a bug that caused the Process not to rebroadcast the fact that a process exited while running a thread plan. For example, if a user types the expression expr (void)exit(0) then the process terminates but LLDB does not notify listeners like Xcode that this occurred. <rdar://problem/11845155> llvm-svn: 160077
2012-07-12 05:31:24 +08:00
if (stop_state != eStateRunning)
{
Reworked the way Process::RunThreadPlan and the ThreadPlanCallFunction interoperate to fix problems where hitting auto-continue signals while running a thread plan would cause us to lose control of the debug session. <rdar://problem/12993641> llvm-svn: 174793
2013-02-09 09:29:05 +08:00
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();
}
Add the ability to set timeout & "run all threads" options both from the "expr" command and from the SB API's that evaluate expressions. <rdar://problem/12457211> llvm-svn: 166062
2012-10-17 05:41:58 +08:00
errors.Printf("Didn't get running event after initial resume, got %s instead.",
StateAsCString(stop_state));
Fixed a bug that caused the Process not to rebroadcast the fact that a process exited while running a thread plan. For example, if a user types the expression expr (void)exit(0) then the process terminates but LLDB does not notify listeners like Xcode that this occurred. <rdar://problem/11845155> llvm-svn: 160077
2012-07-12 05:31:24 +08:00
return_value = eExecutionSetupError;
break;
}
Rework the RunThreadPlan event handling to use Event Hijacking not stopping the event thread. Also clarify the logic of the function. llvm-svn: 125083
2011-02-08 13:20:59 +08:00
if (log)
Fixed a bug that caused the Process not to rebroadcast the fact that a process exited while running a thread plan. For example, if a user types the expression expr (void)exit(0) then the process terminates but LLDB does not notify listeners like Xcode that this occurred. <rdar://problem/11845155> llvm-svn: 160077
2012-07-12 05:31:24 +08:00
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.
Reworked the way Process::RunThreadPlan and the ThreadPlanCallFunction interoperate to fix problems where hitting auto-continue signals while running a thread plan would cause us to lose control of the debug session. <rdar://problem/12993641> llvm-svn: 174793
2013-02-09 09:29:05 +08:00
}
else
{
if (log)
log->PutCString ("Process::RunThreadPlan(): waiting for next event.");
}
Add the ability to set timeout & "run all threads" options both from the "expr" command and from the SB API's that evaluate expressions. <rdar://problem/12457211> llvm-svn: 166062
2012-10-17 05:41:58 +08:00
Reworked the way Process::RunThreadPlan and the ThreadPlanCallFunction interoperate to fix problems where hitting auto-continue signals while running a thread plan would cause us to lose control of the debug session. <rdar://problem/12993641> llvm-svn: 174793
2013-02-09 09:29:05 +08:00
if (before_first_timeout)
{
if (run_others)
timeout_ptr = &one_thread_timeout;
<rdar://problem/11672978> Fixing an issue where an ObjC object might come out without a description because the expression used to obtain it would timeout before running to completion llvm-svn: 160326
2012-07-17 07:10:35 +08:00
else
{
Reworked the way Process::RunThreadPlan and the ThreadPlanCallFunction interoperate to fix problems where hitting auto-continue signals while running a thread plan would cause us to lose control of the debug session. <rdar://problem/12993641> llvm-svn: 174793
2013-02-09 09:29:05 +08:00
if (timeout_usec == 0)
timeout_ptr = NULL;
else
timeout_ptr = &final_timeout;
<rdar://problem/11672978> Fixing an issue where an ObjC object might come out without a description because the expression used to obtain it would timeout before running to completion llvm-svn: 160326
2012-07-17 07:10:35 +08:00
}
Rework the RunThreadPlan event handling to use Event Hijacking not stopping the event thread. Also clarify the logic of the function. llvm-svn: 125083
2011-02-08 13:20:59 +08:00
}
Fixed a bug that caused the Process not to rebroadcast the fact that a process exited while running a thread plan. For example, if a user types the expression expr (void)exit(0) then the process terminates but LLDB does not notify listeners like Xcode that this occurred. <rdar://problem/11845155> llvm-svn: 160077
2012-07-12 05:31:24 +08:00
else
Rework the RunThreadPlan event handling to use Event Hijacking not stopping the event thread. Also clarify the logic of the function. llvm-svn: 125083
2011-02-08 13:20:59 +08:00
{
Reworked the way Process::RunThreadPlan and the ThreadPlanCallFunction interoperate to fix problems where hitting auto-continue signals while running a thread plan would cause us to lose control of the debug session. <rdar://problem/12993641> llvm-svn: 174793
2013-02-09 09:29:05 +08:00
if (timeout_usec == 0)
timeout_ptr = NULL;
else
timeout_ptr = &final_timeout;
Rework the RunThreadPlan event handling to use Event Hijacking not stopping the event thread. Also clarify the logic of the function. llvm-svn: 125083
2011-02-08 13:20:59 +08:00
}
Reworked the way Process::RunThreadPlan and the ThreadPlanCallFunction interoperate to fix problems where hitting auto-continue signals while running a thread plan would cause us to lose control of the debug session. <rdar://problem/12993641> llvm-svn: 174793
2013-02-09 09:29:05 +08:00
do_resume = true;
handle_running_event = true;
Fixed a bug that caused the Process not to rebroadcast the fact that a process exited while running a thread plan. For example, if a user types the expression expr (void)exit(0) then the process terminates but LLDB does not notify listeners like Xcode that this occurred. <rdar://problem/11845155> llvm-svn: 160077
2012-07-12 05:31:24 +08:00
// Now wait for the process to stop again:
event_sp.reset();
The run all threads timeout in RunThreadPlan should respect the user timeout, not be arbitrarily 10 seconds (which was too long anyway...) Also added some logging to RunThreadPlan and made others more regular. llvm-svn: 154708
2012-04-14 07:09:49 +08:00
Fixed a bug that caused the Process not to rebroadcast the fact that a process exited while running a thread plan. For example, if a user types the expression expr (void)exit(0) then the process terminates but LLDB does not notify listeners like Xcode that this occurred. <rdar://problem/11845155> llvm-svn: 160077
2012-07-12 05:31:24 +08:00
if (log)
The run all threads timeout in RunThreadPlan should respect the user timeout, not be arbitrarily 10 seconds (which was too long anyway...) Also added some logging to RunThreadPlan and made others more regular. llvm-svn: 154708
2012-04-14 07:09:49 +08:00
{
Fixed a bug that caused the Process not to rebroadcast the fact that a process exited while running a thread plan. For example, if a user types the expression expr (void)exit(0) then the process terminates but LLDB does not notify listeners like Xcode that this occurred. <rdar://problem/11845155> llvm-svn: 160077
2012-07-12 05:31:24 +08:00
if (timeout_ptr)
{
Fix clang warnings related to python macro redefinition and printf format specifiers. llvm-svn: 175829
2013-02-22 07:55:31 +08:00
log->Printf ("Process::RunThreadPlan(): about to wait - now is %" PRIu64 " - endpoint is %" PRIu64,
Reworked the way Process::RunThreadPlan and the ThreadPlanCallFunction interoperate to fix problems where hitting auto-continue signals while running a thread plan would cause us to lose control of the debug session. <rdar://problem/12993641> llvm-svn: 174793
2013-02-09 09:29:05 +08:00
TimeValue::Now().GetAsMicroSecondsSinceJan1_1970(),
timeout_ptr->GetAsMicroSecondsSinceJan1_1970());
Fixed a bug that caused the Process not to rebroadcast the fact that a process exited while running a thread plan. For example, if a user types the expression expr (void)exit(0) then the process terminates but LLDB does not notify listeners like Xcode that this occurred. <rdar://problem/11845155> llvm-svn: 160077
2012-07-12 05:31:24 +08:00
}
else
{
log->Printf ("Process::RunThreadPlan(): about to wait forever.");
}
The run all threads timeout in RunThreadPlan should respect the user timeout, not be arbitrarily 10 seconds (which was too long anyway...) Also added some logging to RunThreadPlan and made others more regular. llvm-svn: 154708
2012-04-14 07:09:49 +08:00
}
Fixed a bug that caused the Process not to rebroadcast the fact that a process exited while running a thread plan. For example, if a user types the expression expr (void)exit(0) then the process terminates but LLDB does not notify listeners like Xcode that this occurred. <rdar://problem/11845155> llvm-svn: 160077
2012-07-12 05:31:24 +08:00
got_event = listener.WaitForEvent (timeout_ptr, event_sp);
if (got_event)
Rework the RunThreadPlan event handling to use Event Hijacking not stopping the event thread. Also clarify the logic of the function. llvm-svn: 125083
2011-02-08 13:20:59 +08:00
{
Fixed a bug that caused the Process not to rebroadcast the fact that a process exited while running a thread plan. For example, if a user types the expression expr (void)exit(0) then the process terminates but LLDB does not notify listeners like Xcode that this occurred. <rdar://problem/11845155> llvm-svn: 160077
2012-07-12 05:31:24 +08:00
if (event_sp.get())
Rework the RunThreadPlan event handling to use Event Hijacking not stopping the event thread. Also clarify the logic of the function. llvm-svn: 125083
2011-02-08 13:20:59 +08:00
{
Fixed a bug that caused the Process not to rebroadcast the fact that a process exited while running a thread plan. For example, if a user types the expression expr (void)exit(0) then the process terminates but LLDB does not notify listeners like Xcode that this occurred. <rdar://problem/11845155> llvm-svn: 160077
2012-07-12 05:31:24 +08:00
bool keep_going = false;
Added an lldb_private & equivalent SB API to send an AsyncInterrupt to the event loop. Convert from calling Halt in the lldb Driver.cpp's input reader's sigint handler to sending this AsyncInterrupt so it can be handled in the event loop. If you are attaching and get an async interrupt, abort the attach attempt. Also remember to destroy the process if get interrupted while attaching. Getting this to work also required handing the eBroadcastBitInterrupt in a few more places in Process WaitForEvent & friends. <rdar://problem/10792425> llvm-svn: 160903
2012-07-28 07:57:19 +08:00
if (event_sp->GetType() == eBroadcastBitInterrupt)
Fix the error message when an expression evaluation is interrupted by a crash/breakpoint hit to give the reason for the interrupt. Also make sure it we don't want to unwind from the evaluation we print something if it is interrupted. llvm-svn: 131448
2011-05-17 09:10:11 +08:00
{
Added an lldb_private & equivalent SB API to send an AsyncInterrupt to the event loop. Convert from calling Halt in the lldb Driver.cpp's input reader's sigint handler to sending this AsyncInterrupt so it can be handled in the event loop. If you are attaching and get an async interrupt, abort the attach attempt. Also remember to destroy the process if get interrupted while attaching. Getting this to work also required handing the eBroadcastBitInterrupt in a few more places in Process WaitForEvent & friends. <rdar://problem/10792425> llvm-svn: 160903
2012-07-28 07:57:19 +08:00
Halt();
return_value = eExecutionInterrupted;
errors.Printf ("Execution halted by user interrupt.");
if (log)
log->Printf ("Process::RunThreadPlan(): Got interrupted by eBroadcastBitInterrupted, exiting.");
Reworked the way Process::RunThreadPlan and the ThreadPlanCallFunction interoperate to fix problems where hitting auto-continue signals while running a thread plan would cause us to lose control of the debug session. <rdar://problem/12993641> llvm-svn: 174793
2013-02-09 09:29:05 +08:00
break;
Added an lldb_private & equivalent SB API to send an AsyncInterrupt to the event loop. Convert from calling Halt in the lldb Driver.cpp's input reader's sigint handler to sending this AsyncInterrupt so it can be handled in the event loop. If you are attaching and get an async interrupt, abort the attach attempt. Also remember to destroy the process if get interrupted while attaching. Getting this to work also required handing the eBroadcastBitInterrupt in a few more places in Process WaitForEvent & friends. <rdar://problem/10792425> llvm-svn: 160903
2012-07-28 07:57:19 +08:00
}
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)
Fix the error message when an expression evaluation is interrupted by a crash/breakpoint hit to give the reason for the interrupt. Also make sure it we don't want to unwind from the evaluation we print something if it is interrupted. llvm-svn: 131448
2011-05-17 09:10:11 +08:00
{
Added an lldb_private & equivalent SB API to send an AsyncInterrupt to the event loop. Convert from calling Halt in the lldb Driver.cpp's input reader's sigint handler to sending this AsyncInterrupt so it can be handled in the event loop. If you are attaching and get an async interrupt, abort the attach attempt. Also remember to destroy the process if get interrupted while attaching. Getting this to work also required handing the eBroadcastBitInterrupt in a few more places in Process WaitForEvent & friends. <rdar://problem/10792425> llvm-svn: 160903
2012-07-28 07:57:19 +08:00
case lldb::eStateStopped:
Make sure we are ok to stop in a thread plan and have no stop reason for the thread we were running on (other thread crashed or had exceptional stop reason). llvm-svn: 132599
2011-06-04 06:12:42 +08:00
{
Reworked the way Process::RunThreadPlan and the ThreadPlanCallFunction interoperate to fix problems where hitting auto-continue signals while running a thread plan would cause us to lose control of the debug session. <rdar://problem/12993641> llvm-svn: 174793
2013-02-09 09:29:05 +08:00
// We stopped, figure out what we are going to do now.
Added an lldb_private & equivalent SB API to send an AsyncInterrupt to the event loop. Convert from calling Halt in the lldb Driver.cpp's input reader's sigint handler to sending this AsyncInterrupt so it can be handled in the event loop. If you are attaching and get an async interrupt, abort the attach attempt. Also remember to destroy the process if get interrupted while attaching. Getting this to work also required handing the eBroadcastBitInterrupt in a few more places in Process WaitForEvent & friends. <rdar://problem/10792425> llvm-svn: 160903
2012-07-28 07:57:19 +08:00
ThreadSP thread_sp = GetThreadList().FindThreadByIndexID (thread_idx_id);
if (!thread_sp)
Fixed a bug that caused the Process not to rebroadcast the fact that a process exited while running a thread plan. For example, if a user types the expression expr (void)exit(0) then the process terminates but LLDB does not notify listeners like Xcode that this occurred. <rdar://problem/11845155> llvm-svn: 160077
2012-07-12 05:31:24 +08:00
{
Added an lldb_private & equivalent SB API to send an AsyncInterrupt to the event loop. Convert from calling Halt in the lldb Driver.cpp's input reader's sigint handler to sending this AsyncInterrupt so it can be handled in the event loop. If you are attaching and get an async interrupt, abort the attach attempt. Also remember to destroy the process if get interrupted while attaching. Getting this to work also required handing the eBroadcastBitInterrupt in a few more places in Process WaitForEvent & friends. <rdar://problem/10792425> llvm-svn: 160903
2012-07-28 07:57:19 +08:00
// Ooh, our thread has vanished. Unlikely that this was successful execution...
Fixed a bug that caused the Process not to rebroadcast the fact that a process exited while running a thread plan. For example, if a user types the expression expr (void)exit(0) then the process terminates but LLDB does not notify listeners like Xcode that this occurred. <rdar://problem/11845155> llvm-svn: 160077
2012-07-12 05:31:24 +08:00
if (log)
Added an lldb_private & equivalent SB API to send an AsyncInterrupt to the event loop. Convert from calling Halt in the lldb Driver.cpp's input reader's sigint handler to sending this AsyncInterrupt so it can be handled in the event loop. If you are attaching and get an async interrupt, abort the attach attempt. Also remember to destroy the process if get interrupted while attaching. Getting this to work also required handing the eBroadcastBitInterrupt in a few more places in Process WaitForEvent & friends. <rdar://problem/10792425> llvm-svn: 160903
2012-07-28 07:57:19 +08:00
log->Printf ("Process::RunThreadPlan(): execution completed but our thread (index-id=%u) has vanished.", thread_idx_id);
return_value = eExecutionInterrupted;
Fixed a bug that caused the Process not to rebroadcast the fact that a process exited while running a thread plan. For example, if a user types the expression expr (void)exit(0) then the process terminates but LLDB does not notify listeners like Xcode that this occurred. <rdar://problem/11845155> llvm-svn: 160077
2012-07-12 05:31:24 +08:00
}
else
{
Reworked the way Process::RunThreadPlan and the ThreadPlanCallFunction interoperate to fix problems where hitting auto-continue signals while running a thread plan would cause us to lose control of the debug session. <rdar://problem/12993641> llvm-svn: 174793
2013-02-09 09:29:05 +08:00
// If we were restarted, we just need to go back up to fetch another event.
if (Process::ProcessEventData::GetRestartedFromEvent(event_sp.get()))
Added an lldb_private & equivalent SB API to send an AsyncInterrupt to the event loop. Convert from calling Halt in the lldb Driver.cpp's input reader's sigint handler to sending this AsyncInterrupt so it can be handled in the event loop. If you are attaching and get an async interrupt, abort the attach attempt. Also remember to destroy the process if get interrupted while attaching. Getting this to work also required handing the eBroadcastBitInterrupt in a few more places in Process WaitForEvent & friends. <rdar://problem/10792425> llvm-svn: 160903
2012-07-28 07:57:19 +08:00
{
if (log)
Reworked the way Process::RunThreadPlan and the ThreadPlanCallFunction interoperate to fix problems where hitting auto-continue signals while running a thread plan would cause us to lose control of the debug session. <rdar://problem/12993641> llvm-svn: 174793
2013-02-09 09:29:05 +08:00
{
log->Printf ("Process::RunThreadPlan(): Got a stop and restart, so we'll continue waiting.");
}
keep_going = true;
do_resume = false;
handle_running_event = true;
Added an lldb_private & equivalent SB API to send an AsyncInterrupt to the event loop. Convert from calling Halt in the lldb Driver.cpp's input reader's sigint handler to sending this AsyncInterrupt so it can be handled in the event loop. If you are attaching and get an async interrupt, abort the attach attempt. Also remember to destroy the process if get interrupted while attaching. Getting this to work also required handing the eBroadcastBitInterrupt in a few more places in Process WaitForEvent & friends. <rdar://problem/10792425> llvm-svn: 160903
2012-07-28 07:57:19 +08:00
}
else
{
Reworked the way Process::RunThreadPlan and the ThreadPlanCallFunction interoperate to fix problems where hitting auto-continue signals while running a thread plan would cause us to lose control of the debug session. <rdar://problem/12993641> llvm-svn: 174793
2013-02-09 09:29:05 +08:00
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)
Separated the "expr --unwind-on-error" behavior into two parts, actual errors (i.e. crashes) which continue to be controlled by the --unwind-on-error flag, and --ignore-breakpoint which separately controls behavior when a called function hits a breakpoint. For breakpoints, we don't unwind, we either stop, or ignore the breakpoint, which makes more sense. Also make both these behaviors globally settable through "settings set". Also handle the case where a breakpoint command calls code that ends up re-hitting the breakpoint. We were recursing and crashing. Now we just stop without calling the second command. <rdar://problem/12986644> <rdar://problem/9119325> llvm-svn: 172503
2013-01-15 10:47:48 +08:00
{
if (log)
Reworked the way Process::RunThreadPlan and the ThreadPlanCallFunction interoperate to fix problems where hitting auto-continue signals while running a thread plan would cause us to lose control of the debug session. <rdar://problem/12993641> llvm-svn: 174793
2013-02-09 09:29:05 +08:00
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;
Separated the "expr --unwind-on-error" behavior into two parts, actual errors (i.e. crashes) which continue to be controlled by the --unwind-on-error flag, and --ignore-breakpoint which separately controls behavior when a called function hits a breakpoint. For breakpoints, we don't unwind, we either stop, or ignore the breakpoint, which makes more sense. Also make both these behaviors globally settable through "settings set". Also handle the case where a breakpoint command calls code that ends up re-hitting the breakpoint. We were recursing and crashing. Now we just stop without calling the second command. <rdar://problem/12986644> <rdar://problem/9119325> llvm-svn: 172503
2013-01-15 10:47:48 +08:00
}
else
{
Reworked the way Process::RunThreadPlan and the ThreadPlanCallFunction interoperate to fix problems where hitting auto-continue signals while running a thread plan would cause us to lose control of the debug session. <rdar://problem/12993641> llvm-svn: 174793
2013-02-09 09:29:05 +08:00
// Something restarted the target, so just wait for it to stop for real.
Separated the "expr --unwind-on-error" behavior into two parts, actual errors (i.e. crashes) which continue to be controlled by the --unwind-on-error flag, and --ignore-breakpoint which separately controls behavior when a called function hits a breakpoint. For breakpoints, we don't unwind, we either stop, or ignore the breakpoint, which makes more sense. Also make both these behaviors globally settable through "settings set". Also handle the case where a breakpoint command calls code that ends up re-hitting the breakpoint. We were recursing and crashing. Now we just stop without calling the second command. <rdar://problem/12986644> <rdar://problem/9119325> llvm-svn: 172503
2013-01-15 10:47:48 +08:00
if (stop_reason == eStopReasonBreakpoint)
Reworked the way Process::RunThreadPlan and the ThreadPlanCallFunction interoperate to fix problems where hitting auto-continue signals while running a thread plan would cause us to lose control of the debug session. <rdar://problem/12993641> llvm-svn: 174793
2013-02-09 09:29:05 +08:00
{
if (log)
log->Printf ("Process::RunThreadPlan() stopped for breakpoint: %s.", stop_info_sp->GetDescription());
Separated the "expr --unwind-on-error" behavior into two parts, actual errors (i.e. crashes) which continue to be controlled by the --unwind-on-error flag, and --ignore-breakpoint which separately controls behavior when a called function hits a breakpoint. For breakpoints, we don't unwind, we either stop, or ignore the breakpoint, which makes more sense. Also make both these behaviors globally settable through "settings set". Also handle the case where a breakpoint command calls code that ends up re-hitting the breakpoint. We were recursing and crashing. Now we just stop without calling the second command. <rdar://problem/12986644> <rdar://problem/9119325> llvm-svn: 172503
2013-01-15 10:47:48 +08:00
return_value = eExecutionHitBreakpoint;
Reworked the way Process::RunThreadPlan and the ThreadPlanCallFunction interoperate to fix problems where hitting auto-continue signals while running a thread plan would cause us to lose control of the debug session. <rdar://problem/12993641> llvm-svn: 174793
2013-02-09 09:29:05 +08:00
}
Separated the "expr --unwind-on-error" behavior into two parts, actual errors (i.e. crashes) which continue to be controlled by the --unwind-on-error flag, and --ignore-breakpoint which separately controls behavior when a called function hits a breakpoint. For breakpoints, we don't unwind, we either stop, or ignore the breakpoint, which makes more sense. Also make both these behaviors globally settable through "settings set". Also handle the case where a breakpoint command calls code that ends up re-hitting the breakpoint. We were recursing and crashing. Now we just stop without calling the second command. <rdar://problem/12986644> <rdar://problem/9119325> llvm-svn: 172503
2013-01-15 10:47:48 +08:00
else
Reworked the way Process::RunThreadPlan and the ThreadPlanCallFunction interoperate to fix problems where hitting auto-continue signals while running a thread plan would cause us to lose control of the debug session. <rdar://problem/12993641> llvm-svn: 174793
2013-02-09 09:29:05 +08:00
{
if (log)
log->PutCString ("Process::RunThreadPlan(): thread plan didn't successfully complete.");
Separated the "expr --unwind-on-error" behavior into two parts, actual errors (i.e. crashes) which continue to be controlled by the --unwind-on-error flag, and --ignore-breakpoint which separately controls behavior when a called function hits a breakpoint. For breakpoints, we don't unwind, we either stop, or ignore the breakpoint, which makes more sense. Also make both these behaviors globally settable through "settings set". Also handle the case where a breakpoint command calls code that ends up re-hitting the breakpoint. We were recursing and crashing. Now we just stop without calling the second command. <rdar://problem/12986644> <rdar://problem/9119325> llvm-svn: 172503
2013-01-15 10:47:48 +08:00
return_value = eExecutionInterrupted;
Reworked the way Process::RunThreadPlan and the ThreadPlanCallFunction interoperate to fix problems where hitting auto-continue signals while running a thread plan would cause us to lose control of the debug session. <rdar://problem/12993641> llvm-svn: 174793
2013-02-09 09:29:05 +08:00
}
Separated the "expr --unwind-on-error" behavior into two parts, actual errors (i.e. crashes) which continue to be controlled by the --unwind-on-error flag, and --ignore-breakpoint which separately controls behavior when a called function hits a breakpoint. For breakpoints, we don't unwind, we either stop, or ignore the breakpoint, which makes more sense. Also make both these behaviors globally settable through "settings set". Also handle the case where a breakpoint command calls code that ends up re-hitting the breakpoint. We were recursing and crashing. Now we just stop without calling the second command. <rdar://problem/12986644> <rdar://problem/9119325> llvm-svn: 172503
2013-01-15 10:47:48 +08:00
}
Added an lldb_private & equivalent SB API to send an AsyncInterrupt to the event loop. Convert from calling Halt in the lldb Driver.cpp's input reader's sigint handler to sending this AsyncInterrupt so it can be handled in the event loop. If you are attaching and get an async interrupt, abort the attach attempt. Also remember to destroy the process if get interrupted while attaching. Getting this to work also required handing the eBroadcastBitInterrupt in a few more places in Process WaitForEvent & friends. <rdar://problem/10792425> llvm-svn: 160903
2012-07-28 07:57:19 +08:00
}
Fixed a bug that caused the Process not to rebroadcast the fact that a process exited while running a thread plan. For example, if a user types the expression expr (void)exit(0) then the process terminates but LLDB does not notify listeners like Xcode that this occurred. <rdar://problem/11845155> llvm-svn: 160077
2012-07-12 05:31:24 +08:00
}
Added an lldb_private & equivalent SB API to send an AsyncInterrupt to the event loop. Convert from calling Halt in the lldb Driver.cpp's input reader's sigint handler to sending this AsyncInterrupt so it can be handled in the event loop. If you are attaching and get an async interrupt, abort the attach attempt. Also remember to destroy the process if get interrupted while attaching. Getting this to work also required handing the eBroadcastBitInterrupt in a few more places in Process WaitForEvent & friends. <rdar://problem/10792425> llvm-svn: 160903
2012-07-28 07:57:19 +08:00
}
break;
Make sure we are ok to stop in a thread plan and have no stop reason for the thread we were running on (other thread crashed or had exceptional stop reason). llvm-svn: 132599
2011-06-04 06:12:42 +08:00
Added an lldb_private & equivalent SB API to send an AsyncInterrupt to the event loop. Convert from calling Halt in the lldb Driver.cpp's input reader's sigint handler to sending this AsyncInterrupt so it can be handled in the event loop. If you are attaching and get an async interrupt, abort the attach attempt. Also remember to destroy the process if get interrupted while attaching. Getting this to work also required handing the eBroadcastBitInterrupt in a few more places in Process WaitForEvent & friends. <rdar://problem/10792425> llvm-svn: 160903
2012-07-28 07:57:19 +08:00
case lldb::eStateRunning:
Reworked the way Process::RunThreadPlan and the ThreadPlanCallFunction interoperate to fix problems where hitting auto-continue signals while running a thread plan would cause us to lose control of the debug session. <rdar://problem/12993641> llvm-svn: 174793
2013-02-09 09:29:05 +08:00
// 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.
Added an lldb_private & equivalent SB API to send an AsyncInterrupt to the event loop. Convert from calling Halt in the lldb Driver.cpp's input reader's sigint handler to sending this AsyncInterrupt so it can be handled in the event loop. If you are attaching and get an async interrupt, abort the attach attempt. Also remember to destroy the process if get interrupted while attaching. Getting this to work also required handing the eBroadcastBitInterrupt in a few more places in Process WaitForEvent & friends. <rdar://problem/10792425> llvm-svn: 160903
2012-07-28 07:57:19 +08:00
do_resume = false;
keep_going = true;
Separated the "expr --unwind-on-error" behavior into two parts, actual errors (i.e. crashes) which continue to be controlled by the --unwind-on-error flag, and --ignore-breakpoint which separately controls behavior when a called function hits a breakpoint. For breakpoints, we don't unwind, we either stop, or ignore the breakpoint, which makes more sense. Also make both these behaviors globally settable through "settings set". Also handle the case where a breakpoint command calls code that ends up re-hitting the breakpoint. We were recursing and crashing. Now we just stop without calling the second command. <rdar://problem/12986644> <rdar://problem/9119325> llvm-svn: 172503
2013-01-15 10:47:48 +08:00
handle_running_event = false;
Added an lldb_private & equivalent SB API to send an AsyncInterrupt to the event loop. Convert from calling Halt in the lldb Driver.cpp's input reader's sigint handler to sending this AsyncInterrupt so it can be handled in the event loop. If you are attaching and get an async interrupt, abort the attach attempt. Also remember to destroy the process if get interrupted while attaching. Getting this to work also required handing the eBroadcastBitInterrupt in a few more places in Process WaitForEvent & friends. <rdar://problem/10792425> llvm-svn: 160903
2012-07-28 07:57:19 +08:00
break;
Make sure we are ok to stop in a thread plan and have no stop reason for the thread we were running on (other thread crashed or had exceptional stop reason). llvm-svn: 132599
2011-06-04 06:12:42 +08:00
Added an lldb_private & equivalent SB API to send an AsyncInterrupt to the event loop. Convert from calling Halt in the lldb Driver.cpp's input reader's sigint handler to sending this AsyncInterrupt so it can be handled in the event loop. If you are attaching and get an async interrupt, abort the attach attempt. Also remember to destroy the process if get interrupted while attaching. Getting this to work also required handing the eBroadcastBitInterrupt in a few more places in Process WaitForEvent & friends. <rdar://problem/10792425> llvm-svn: 160903
2012-07-28 07:57:19 +08:00
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;
Added a 'void' format so that the user can manually suppress all non-error output from the "expression" command. <rdar://problem/11225150> llvm-svn: 161502
2012-08-09 01:35:10 +08:00
errors.Printf ("Execution stopped with unexpected state.\n");
Added an lldb_private & equivalent SB API to send an AsyncInterrupt to the event loop. Convert from calling Halt in the lldb Driver.cpp's input reader's sigint handler to sending this AsyncInterrupt so it can be handled in the event loop. If you are attaching and get an async interrupt, abort the attach attempt. Also remember to destroy the process if get interrupted while attaching. Getting this to work also required handing the eBroadcastBitInterrupt in a few more places in Process WaitForEvent & friends. <rdar://problem/10792425> llvm-svn: 160903
2012-07-28 07:57:19 +08:00
return_value = eExecutionInterrupted;
break;
}
Fixed a bug that caused the Process not to rebroadcast the fact that a process exited while running a thread plan. For example, if a user types the expression expr (void)exit(0) then the process terminates but LLDB does not notify listeners like Xcode that this occurred. <rdar://problem/11845155> llvm-svn: 160077
2012-07-12 05:31:24 +08:00
}
Added an lldb_private & equivalent SB API to send an AsyncInterrupt to the event loop. Convert from calling Halt in the lldb Driver.cpp's input reader's sigint handler to sending this AsyncInterrupt so it can be handled in the event loop. If you are attaching and get an async interrupt, abort the attach attempt. Also remember to destroy the process if get interrupted while attaching. Getting this to work also required handing the eBroadcastBitInterrupt in a few more places in Process WaitForEvent & friends. <rdar://problem/10792425> llvm-svn: 160903
2012-07-28 07:57:19 +08:00
Fixed a bug that caused the Process not to rebroadcast the fact that a process exited while running a thread plan. For example, if a user types the expression expr (void)exit(0) then the process terminates but LLDB does not notify listeners like Xcode that this occurred. <rdar://problem/11845155> llvm-svn: 160077
2012-07-12 05:31:24 +08:00
if (keep_going)
continue;
else
break;
}
else
{
Rework the RunThreadPlan event handling to use Event Hijacking not stopping the event thread. Also clarify the logic of the function. llvm-svn: 125083
2011-02-08 13:20:59 +08:00
if (log)
Fixed a bug that caused the Process not to rebroadcast the fact that a process exited while running a thread plan. For example, if a user types the expression expr (void)exit(0) then the process terminates but LLDB does not notify listeners like Xcode that this occurred. <rdar://problem/11845155> llvm-svn: 160077
2012-07-12 05:31:24 +08:00
log->PutCString ("Process::RunThreadPlan(): got_event was true, but the event pointer was null. How odd...");
Fixed the LLDB build so that we can have private types, private enums and public types and public enums. This was done to keep the SWIG stuff from parsing all sorts of enums and types that weren't needed, and allows us to abstract our API better. llvm-svn: 128239
2011-03-25 05:19:54 +08:00
return_value = eExecutionInterrupted;
Rework the RunThreadPlan event handling to use Event Hijacking not stopping the event thread. Also clarify the logic of the function. llvm-svn: 125083
2011-02-08 13:20:59 +08:00
break;
}
Fixed a bug that caused the Process not to rebroadcast the fact that a process exited while running a thread plan. For example, if a user types the expression expr (void)exit(0) then the process terminates but LLDB does not notify listeners like Xcode that this occurred. <rdar://problem/11845155> llvm-svn: 160077
2012-07-12 05:31:24 +08:00
}
Rework the RunThreadPlan event handling to use Event Hijacking not stopping the event thread. Also clarify the logic of the function. llvm-svn: 125083
2011-02-08 13:20:59 +08:00
else
{
Fixed a bug that caused the Process not to rebroadcast the fact that a process exited while running a thread plan. For example, if a user types the expression expr (void)exit(0) then the process terminates but LLDB does not notify listeners like Xcode that this occurred. <rdar://problem/11845155> llvm-svn: 160077
2012-07-12 05:31:24 +08:00
// 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) {
Add the ability to set timeout & "run all threads" options both from the "expr" command and from the SB API's that evaluate expressions. <rdar://problem/12457211> llvm-svn: 166062
2012-10-17 05:41:58 +08:00
if (run_others)
Fixed a bug that caused the Process not to rebroadcast the fact that a process exited while running a thread plan. For example, if a user types the expression expr (void)exit(0) then the process terminates but LLDB does not notify listeners like Xcode that this occurred. <rdar://problem/11845155> llvm-svn: 160077
2012-07-12 05:31:24 +08:00
{
Reworked the way Process::RunThreadPlan and the ThreadPlanCallFunction interoperate to fix problems where hitting auto-continue signals while running a thread plan would cause us to lose control of the debug session. <rdar://problem/12993641> llvm-svn: 174793
2013-02-09 09:29:05 +08:00
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 %" PRId64 " usec with all threads enabled.",
remaining_time);
Fixed a bug that caused the Process not to rebroadcast the fact that a process exited while running a thread plan. For example, if a user types the expression expr (void)exit(0) then the process terminates but LLDB does not notify listeners like Xcode that this occurred. <rdar://problem/11845155> llvm-svn: 160077
2012-07-12 05:31:24 +08:00
else
log->Printf ("Process::RunThreadPlan(): Restarting function with all threads enabled "
Add the ability to set timeout & "run all threads" options both from the "expr" command and from the SB API's that evaluate expressions. <rdar://problem/12457211> llvm-svn: 166062
2012-10-17 05:41:58 +08:00
"and timeout: %d timed out, abandoning execution.",
timeout_usec);
Fixed a bug that caused the Process not to rebroadcast the fact that a process exited while running a thread plan. For example, if a user types the expression expr (void)exit(0) then the process terminates but LLDB does not notify listeners like Xcode that this occurred. <rdar://problem/11845155> llvm-svn: 160077
2012-07-12 05:31:24 +08:00
}
Rework the RunThreadPlan event handling to use Event Hijacking not stopping the event thread. Also clarify the logic of the function. llvm-svn: 125083
2011-02-08 13:20:59 +08:00
else
Fixed a bug that caused the Process not to rebroadcast the fact that a process exited while running a thread plan. For example, if a user types the expression expr (void)exit(0) then the process terminates but LLDB does not notify listeners like Xcode that this occurred. <rdar://problem/11845155> llvm-svn: 160077
2012-07-12 05:31:24 +08:00
log->Printf ("Process::RunThreadPlan(): Running function with timeout: %d timed out, "
Add the ability to set timeout & "run all threads" options both from the "expr" command and from the SB API's that evaluate expressions. <rdar://problem/12457211> llvm-svn: 166062
2012-10-17 05:41:58 +08:00
"abandoning execution.",
timeout_usec);
Rework the RunThreadPlan event handling to use Event Hijacking not stopping the event thread. Also clarify the logic of the function. llvm-svn: 125083
2011-02-08 13:20:59 +08:00
}
Reworked the way Process::RunThreadPlan and the ThreadPlanCallFunction interoperate to fix problems where hitting auto-continue signals while running a thread plan would cause us to lose control of the debug session. <rdar://problem/12993641> llvm-svn: 174793
2013-02-09 09:29:05 +08:00
// 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)
Rework the RunThreadPlan event handling to use Event Hijacking not stopping the event thread. Also clarify the logic of the function. llvm-svn: 125083
2011-02-08 13:20:59 +08:00
{
Reworked the way Process::RunThreadPlan and the ThreadPlanCallFunction interoperate to fix problems where hitting auto-continue signals while running a thread plan would cause us to lose control of the debug session. <rdar://problem/12993641> llvm-svn: 174793
2013-02-09 09:29:05 +08:00
Error halt_error;
if (do_halt)
Rework the RunThreadPlan event handling to use Event Hijacking not stopping the event thread. Also clarify the logic of the function. llvm-svn: 125083
2011-02-08 13:20:59 +08:00
{
Fixed a bug that caused the Process not to rebroadcast the fact that a process exited while running a thread plan. For example, if a user types the expression expr (void)exit(0) then the process terminates but LLDB does not notify listeners like Xcode that this occurred. <rdar://problem/11845155> llvm-svn: 160077
2012-07-12 05:31:24 +08:00
if (log)
Reworked the way Process::RunThreadPlan and the ThreadPlanCallFunction interoperate to fix problems where hitting auto-continue signals while running a thread plan would cause us to lose control of the debug session. <rdar://problem/12993641> llvm-svn: 174793
2013-02-09 09:29:05 +08:00
log->Printf ("Process::RunThreadPlan(): Running Halt.");
halt_error = Halt();
Fixed a bug that caused the Process not to rebroadcast the fact that a process exited while running a thread plan. For example, if a user types the expression expr (void)exit(0) then the process terminates but LLDB does not notify listeners like Xcode that this occurred. <rdar://problem/11845155> llvm-svn: 160077
2012-07-12 05:31:24 +08:00
}
Reworked the way Process::RunThreadPlan and the ThreadPlanCallFunction interoperate to fix problems where hitting auto-continue signals while running a thread plan would cause us to lose control of the debug session. <rdar://problem/12993641> llvm-svn: 174793
2013-02-09 09:29:05 +08:00
if (halt_error.Success())
Fixed a bug that caused the Process not to rebroadcast the fact that a process exited while running a thread plan. For example, if a user types the expression expr (void)exit(0) then the process terminates but LLDB does not notify listeners like Xcode that this occurred. <rdar://problem/11845155> llvm-svn: 160077
2012-07-12 05:31:24 +08:00
{
if (log)
Reworked the way Process::RunThreadPlan and the ThreadPlanCallFunction interoperate to fix problems where hitting auto-continue signals while running a thread plan would cause us to lose control of the debug session. <rdar://problem/12993641> llvm-svn: 174793
2013-02-09 09:29:05 +08:00
log->PutCString ("Process::RunThreadPlan(): Halt succeeded.");
Fixed a bug that caused the Process not to rebroadcast the fact that a process exited while running a thread plan. For example, if a user types the expression expr (void)exit(0) then the process terminates but LLDB does not notify listeners like Xcode that this occurred. <rdar://problem/11845155> llvm-svn: 160077
2012-07-12 05:31:24 +08:00
Reworked the way Process::RunThreadPlan and the ThreadPlanCallFunction interoperate to fix problems where hitting auto-continue signals while running a thread plan would cause us to lose control of the debug session. <rdar://problem/12993641> llvm-svn: 174793
2013-02-09 09:29:05 +08:00
real_timeout = TimeValue::Now();
real_timeout.OffsetWithMicroSeconds(500000);
Rework the RunThreadPlan event handling to use Event Hijacking not stopping the event thread. Also clarify the logic of the function. llvm-svn: 125083
2011-02-08 13:20:59 +08:00
Reworked the way Process::RunThreadPlan and the ThreadPlanCallFunction interoperate to fix problems where hitting auto-continue signals while running a thread plan would cause us to lose control of the debug session. <rdar://problem/12993641> llvm-svn: 174793
2013-02-09 09:29:05 +08:00
got_event = listener.WaitForEvent(&real_timeout, event_sp);
if (got_event)
{
stop_state = Process::ProcessEventData::GetStateFromEvent(event_sp.get());
if (log)
Fixed a bug that caused the Process not to rebroadcast the fact that a process exited while running a thread plan. For example, if a user types the expression expr (void)exit(0) then the process terminates but LLDB does not notify listeners like Xcode that this occurred. <rdar://problem/11845155> llvm-svn: 160077
2012-07-12 05:31:24 +08:00
{
Reworked the way Process::RunThreadPlan and the ThreadPlanCallFunction interoperate to fix problems where hitting auto-continue signals while running a thread plan would cause us to lose control of the debug session. <rdar://problem/12993641> llvm-svn: 174793
2013-02-09 09:29:05 +08:00
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.");
Fixed a bug that caused the Process not to rebroadcast the fact that a process exited while running a thread plan. For example, if a user types the expression expr (void)exit(0) then the process terminates but LLDB does not notify listeners like Xcode that this occurred. <rdar://problem/11845155> llvm-svn: 160077
2012-07-12 05:31:24 +08:00
}
Reworked the way Process::RunThreadPlan and the ThreadPlanCallFunction interoperate to fix problems where hitting auto-continue signals while running a thread plan would cause us to lose control of the debug session. <rdar://problem/12993641> llvm-svn: 174793
2013-02-09 09:29:05 +08:00
if (stop_state == lldb::eStateStopped)
Fixed a bug that caused the Process not to rebroadcast the fact that a process exited while running a thread plan. For example, if a user types the expression expr (void)exit(0) then the process terminates but LLDB does not notify listeners like Xcode that this occurred. <rdar://problem/11845155> llvm-svn: 160077
2012-07-12 05:31:24 +08:00
{
Reworked the way Process::RunThreadPlan and the ThreadPlanCallFunction interoperate to fix problems where hitting auto-continue signals while running a thread plan would cause us to lose control of the debug session. <rdar://problem/12993641> llvm-svn: 174793
2013-02-09 09:29:05 +08:00
// 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 (!run_others)
{
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;
}
Fixed a bug that caused the Process not to rebroadcast the fact that a process exited while running a thread plan. For example, if a user types the expression expr (void)exit(0) then the process terminates but LLDB does not notify listeners like Xcode that this occurred. <rdar://problem/11845155> llvm-svn: 160077
2012-07-12 05:31:24 +08:00
}
Rework the RunThreadPlan event handling to use Event Hijacking not stopping the event thread. Also clarify the logic of the function. llvm-svn: 125083
2011-02-08 13:20:59 +08:00
}
else
Reworked the way Process::RunThreadPlan and the ThreadPlanCallFunction interoperate to fix problems where hitting auto-continue signals while running a thread plan would cause us to lose control of the debug session. <rdar://problem/12993641> llvm-svn: 174793
2013-02-09 09:29:05 +08:00
{ if (log)
log->PutCString("Process::RunThreadPlan(): halt said it succeeded, but I got no event. "
"I'm getting out of here passing Interrupted.");
Fixed the LLDB build so that we can have private types, private enums and public types and public enums. This was done to keep the SWIG stuff from parsing all sorts of enums and types that weren't needed, and allows us to abstract our API better. llvm-svn: 128239
2011-03-25 05:19:54 +08:00
return_value = eExecutionInterrupted;
Reworked the way Process::RunThreadPlan and the ThreadPlanCallFunction interoperate to fix problems where hitting auto-continue signals while running a thread plan would cause us to lose control of the debug session. <rdar://problem/12993641> llvm-svn: 174793
2013-02-09 09:29:05 +08:00
back_to_top = false;
break;
Rework the RunThreadPlan event handling to use Event Hijacking not stopping the event thread. Also clarify the logic of the function. llvm-svn: 125083
2011-02-08 13:20:59 +08:00
}
}
Reworked the way Process::RunThreadPlan and the ThreadPlanCallFunction interoperate to fix problems where hitting auto-continue signals while running a thread plan would cause us to lose control of the debug session. <rdar://problem/12993641> llvm-svn: 174793
2013-02-09 09:29:05 +08:00
else
{
try_halt_again++;
continue;
}
Add some more logging of broadcaster and Process. Also, protect the event broadcasting against hijacking in mid-event delivery. llvm-svn: 124084
2011-01-24 05:14:08 +08:00
}
Reworked the way Process::RunThreadPlan and the ThreadPlanCallFunction interoperate to fix problems where hitting auto-continue signals while running a thread plan would cause us to lose control of the debug session. <rdar://problem/12993641> llvm-svn: 174793
2013-02-09 09:29:05 +08:00
if (!back_to_top || try_halt_again > num_retries)
break;
else
continue;
Fixed a bug that caused the Process not to rebroadcast the fact that a process exited while running a thread plan. For example, if a user types the expression expr (void)exit(0) then the process terminates but LLDB does not notify listeners like Xcode that this occurred. <rdar://problem/11845155> llvm-svn: 160077
2012-07-12 05:31:24 +08:00
}
} // END WAIT LOOP
Moved the code in ClangUserExpression that set up & ran the thread plan with timeouts, and restarting with all threads into a utility function in Process. This required a bunch of renaming. Added a ThreadPlanCallUserExpression that differs from ThreadPlanCallFunction in that it holds onto a shared pointer to its ClangUserExpression so that can't go away before the thread plan is done using it. Fixed the stop message when you hit a breakpoint while running a user expression so it is more obvious what has happened. llvm-svn: 120386
2010-11-30 10:22:11 +08:00
Fixed a bug that caused the Process not to rebroadcast the fact that a process exited while running a thread plan. For example, if a user types the expression expr (void)exit(0) then the process terminates but LLDB does not notify listeners like Xcode that this occurred. <rdar://problem/11845155> llvm-svn: 160077
2012-07-12 05:31:24 +08:00
// 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))
Two changes, 1) Start the PrivateStateThread stopped, and then in StartPrivateStateThread, make the private state thread and then resume it before we say the thread is created. That way we know it is listening for events by the time we get out of StartPrivateStateThread. 2) Backstop running a thread plan when calling Process::RunThreadPlan on the private state thread with a ThreadPlanBase so that running the plan doesn't pass its stop events to whatever plans happen to be above us on the thread plan stack. llvm-svn: 154368
2012-04-10 09:21:57 +08:00
{
Fixed a bug that caused the Process not to rebroadcast the fact that a process exited while running a thread plan. For example, if a user types the expression expr (void)exit(0) then the process terminates but LLDB does not notify listeners like Xcode that this occurred. <rdar://problem/11845155> llvm-svn: 160077
2012-07-12 05:31:24 +08:00
StopPrivateStateThread();
Error error;
m_private_state_thread = backup_private_state_thread;
Removed explicit NULL checks for shared pointers and instead made us use implicit casts to bool. This generated a warning in C++11. <rdar://problem/11930775> llvm-svn: 161559
2012-08-09 08:50:26 +08:00
if (stopper_base_plan_sp)
Moved the code in ClangUserExpression that set up & ran the thread plan with timeouts, and restarting with all threads into a utility function in Process. This required a bunch of renaming. Added a ThreadPlanCallUserExpression that differs from ThreadPlanCallFunction in that it holds onto a shared pointer to its ClangUserExpression so that can't go away before the thread plan is done using it. Fixed the stop message when you hit a breakpoint while running a user expression so it is more obvious what has happened. llvm-svn: 120386
2010-11-30 10:22:11 +08:00
{
Fixed a bug that caused the Process not to rebroadcast the fact that a process exited while running a thread plan. For example, if a user types the expression expr (void)exit(0) then the process terminates but LLDB does not notify listeners like Xcode that this occurred. <rdar://problem/11845155> llvm-svn: 160077
2012-07-12 05:31:24 +08:00
thread->DiscardThreadPlansUpToPlan(stopper_base_plan_sp);
Rework the RunThreadPlan event handling to use Event Hijacking not stopping the event thread. Also clarify the logic of the function. llvm-svn: 125083
2011-02-08 13:20:59 +08:00
}
Fixed a bug that caused the Process not to rebroadcast the fact that a process exited while running a thread plan. For example, if a user types the expression expr (void)exit(0) then the process terminates but LLDB does not notify listeners like Xcode that this occurred. <rdar://problem/11845155> llvm-svn: 160077
2012-07-12 05:31:24 +08:00
m_public_state.SetValueNoLock(old_state);
Rework the RunThreadPlan event handling to use Event Hijacking not stopping the event thread. Also clarify the logic of the function. llvm-svn: 125083
2011-02-08 13:20:59 +08:00
Fixed a bug that caused the Process not to rebroadcast the fact that a process exited while running a thread plan. For example, if a user types the expression expr (void)exit(0) then the process terminates but LLDB does not notify listeners like Xcode that this occurred. <rdar://problem/11845155> llvm-svn: 160077
2012-07-12 05:31:24 +08:00
}
Separated the "expr --unwind-on-error" behavior into two parts, actual errors (i.e. crashes) which continue to be controlled by the --unwind-on-error flag, and --ignore-breakpoint which separately controls behavior when a called function hits a breakpoint. For breakpoints, we don't unwind, we either stop, or ignore the breakpoint, which makes more sense. Also make both these behaviors globally settable through "settings set". Also handle the case where a breakpoint command calls code that ends up re-hitting the breakpoint. We were recursing and crashing. Now we just stop without calling the second command. <rdar://problem/12986644> <rdar://problem/9119325> llvm-svn: 172503
2013-01-15 10:47:48 +08:00
// 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 && unwind_on_error)
|| (return_value == eExecutionHitBreakpoint && ignore_breakpoints);
The Function calling thread plan was replacing the stored stop info too soon, causing recursive entry into the breakpoint StopInfo's PerformAction, which is bad. Reworked this so that it is now correct. <rdar://problem/12501259> llvm-svn: 168634
2012-11-27 07:52:18 +08:00
Separated the "expr --unwind-on-error" behavior into two parts, actual errors (i.e. crashes) which continue to be controlled by the --unwind-on-error flag, and --ignore-breakpoint which separately controls behavior when a called function hits a breakpoint. For breakpoints, we don't unwind, we either stop, or ignore the breakpoint, which makes more sense. Also make both these behaviors globally settable through "settings set". Also handle the case where a breakpoint command calls code that ends up re-hitting the breakpoint. We were recursing and crashing. Now we just stop without calling the second command. <rdar://problem/12986644> <rdar://problem/9119325> llvm-svn: 172503
2013-01-15 10:47:48 +08:00
if (return_value == eExecutionCompleted
|| should_unwind)
The Function calling thread plan was replacing the stored stop info too soon, causing recursive entry into the breakpoint StopInfo's PerformAction, which is bad. Reworked this so that it is now correct. <rdar://problem/12501259> llvm-svn: 168634
2012-11-27 07:52:18 +08:00
{
thread_plan_sp->RestoreThreadState();
}
Fixed a bug that caused the Process not to rebroadcast the fact that a process exited while running a thread plan. For example, if a user types the expression expr (void)exit(0) then the process terminates but LLDB does not notify listeners like Xcode that this occurred. <rdar://problem/11845155> llvm-svn: 160077
2012-07-12 05:31:24 +08:00
// Now do some processing on the results of the run:
Separated the "expr --unwind-on-error" behavior into two parts, actual errors (i.e. crashes) which continue to be controlled by the --unwind-on-error flag, and --ignore-breakpoint which separately controls behavior when a called function hits a breakpoint. For breakpoints, we don't unwind, we either stop, or ignore the breakpoint, which makes more sense. Also make both these behaviors globally settable through "settings set". Also handle the case where a breakpoint command calls code that ends up re-hitting the breakpoint. We were recursing and crashing. Now we just stop without calling the second command. <rdar://problem/12986644> <rdar://problem/9119325> llvm-svn: 172503
2013-01-15 10:47:48 +08:00
if (return_value == eExecutionInterrupted || return_value == eExecutionHitBreakpoint)
Fixed a bug that caused the Process not to rebroadcast the fact that a process exited while running a thread plan. For example, if a user types the expression expr (void)exit(0) then the process terminates but LLDB does not notify listeners like Xcode that this occurred. <rdar://problem/11845155> llvm-svn: 160077
2012-07-12 05:31:24 +08:00
{
if (log)
Rework the RunThreadPlan event handling to use Event Hijacking not stopping the event thread. Also clarify the logic of the function. llvm-svn: 125083
2011-02-08 13:20:59 +08:00
{
Fixed a bug that caused the Process not to rebroadcast the fact that a process exited while running a thread plan. For example, if a user types the expression expr (void)exit(0) then the process terminates but LLDB does not notify listeners like Xcode that this occurred. <rdar://problem/11845155> llvm-svn: 160077
2012-07-12 05:31:24 +08:00
StreamString s;
if (event_sp)
event_sp->Dump (&s);
else
Add more logging. Try to handle the case where "Halt" fails. This is kind of a losing game in the end, if we can't halt the target, it is not clear what we can do but keep trying... llvm-svn: 124017
2011-01-22 09:30:53 +08:00
{
Fixed a bug that caused the Process not to rebroadcast the fact that a process exited while running a thread plan. For example, if a user types the expression expr (void)exit(0) then the process terminates but LLDB does not notify listeners like Xcode that this occurred. <rdar://problem/11845155> llvm-svn: 160077
2012-07-12 05:31:24 +08:00
log->PutCString ("Process::RunThreadPlan(): Stop event that interrupted us is NULL.");
Add more logging. Try to handle the case where "Halt" fails. This is kind of a losing game in the end, if we can't halt the target, it is not clear what we can do but keep trying... llvm-svn: 124017
2011-01-22 09:30:53 +08:00
}
Fixed a bug that caused the Process not to rebroadcast the fact that a process exited while running a thread plan. For example, if a user types the expression expr (void)exit(0) then the process terminates but LLDB does not notify listeners like Xcode that this occurred. <rdar://problem/11845155> llvm-svn: 160077
2012-07-12 05:31:24 +08:00
StreamString ts;
const char *event_explanation = NULL;
Moved the code in ClangUserExpression that set up & ran the thread plan with timeouts, and restarting with all threads into a utility function in Process. This required a bunch of renaming. Added a ThreadPlanCallUserExpression that differs from ThreadPlanCallFunction in that it holds onto a shared pointer to its ClangUserExpression so that can't go away before the thread plan is done using it. Fixed the stop message when you hit a breakpoint while running a user expression so it is more obvious what has happened. llvm-svn: 120386
2010-11-30 10:22:11 +08:00
Fixed a bug that caused the Process not to rebroadcast the fact that a process exited while running a thread plan. For example, if a user types the expression expr (void)exit(0) then the process terminates but LLDB does not notify listeners like Xcode that this occurred. <rdar://problem/11845155> llvm-svn: 160077
2012-07-12 05:31:24 +08:00
do
Moved the code in ClangUserExpression that set up & ran the thread plan with timeouts, and restarting with all threads into a utility function in Process. This required a bunch of renaming. Added a ThreadPlanCallUserExpression that differs from ThreadPlanCallFunction in that it holds onto a shared pointer to its ClangUserExpression so that can't go away before the thread plan is done using it. Fixed the stop message when you hit a breakpoint while running a user expression so it is more obvious what has happened. llvm-svn: 120386
2010-11-30 10:22:11 +08:00
{
Added an lldb_private & equivalent SB API to send an AsyncInterrupt to the event loop. Convert from calling Halt in the lldb Driver.cpp's input reader's sigint handler to sending this AsyncInterrupt so it can be handled in the event loop. If you are attaching and get an async interrupt, abort the attach attempt. Also remember to destroy the process if get interrupted while attaching. Getting this to work also required handing the eBroadcastBitInterrupt in a few more places in Process WaitForEvent & friends. <rdar://problem/10792425> llvm-svn: 160903
2012-07-28 07:57:19 +08:00
if (!event_sp)
Fixed a bug that caused the Process not to rebroadcast the fact that a process exited while running a thread plan. For example, if a user types the expression expr (void)exit(0) then the process terminates but LLDB does not notify listeners like Xcode that this occurred. <rdar://problem/11845155> llvm-svn: 160077
2012-07-12 05:31:24 +08:00
{
Added an lldb_private & equivalent SB API to send an AsyncInterrupt to the event loop. Convert from calling Halt in the lldb Driver.cpp's input reader's sigint handler to sending this AsyncInterrupt so it can be handled in the event loop. If you are attaching and get an async interrupt, abort the attach attempt. Also remember to destroy the process if get interrupted while attaching. Getting this to work also required handing the eBroadcastBitInterrupt in a few more places in Process WaitForEvent & friends. <rdar://problem/10792425> llvm-svn: 160903
2012-07-28 07:57:19 +08:00
event_explanation = "<no event>";
Fixed a bug that caused the Process not to rebroadcast the fact that a process exited while running a thread plan. For example, if a user types the expression expr (void)exit(0) then the process terminates but LLDB does not notify listeners like Xcode that this occurred. <rdar://problem/11845155> llvm-svn: 160077
2012-07-12 05:31:24 +08:00
break;
}
Added an lldb_private & equivalent SB API to send an AsyncInterrupt to the event loop. Convert from calling Halt in the lldb Driver.cpp's input reader's sigint handler to sending this AsyncInterrupt so it can be handled in the event loop. If you are attaching and get an async interrupt, abort the attach attempt. Also remember to destroy the process if get interrupted while attaching. Getting this to work also required handing the eBroadcastBitInterrupt in a few more places in Process WaitForEvent & friends. <rdar://problem/10792425> llvm-svn: 160903
2012-07-28 07:57:19 +08:00
else if (event_sp->GetType() == eBroadcastBitInterrupt)
Moved the code in ClangUserExpression that set up & ran the thread plan with timeouts, and restarting with all threads into a utility function in Process. This required a bunch of renaming. Added a ThreadPlanCallUserExpression that differs from ThreadPlanCallFunction in that it holds onto a shared pointer to its ClangUserExpression so that can't go away before the thread plan is done using it. Fixed the stop message when you hit a breakpoint while running a user expression so it is more obvious what has happened. llvm-svn: 120386
2010-11-30 10:22:11 +08:00
{
Added an lldb_private & equivalent SB API to send an AsyncInterrupt to the event loop. Convert from calling Halt in the lldb Driver.cpp's input reader's sigint handler to sending this AsyncInterrupt so it can be handled in the event loop. If you are attaching and get an async interrupt, abort the attach attempt. Also remember to destroy the process if get interrupted while attaching. Getting this to work also required handing the eBroadcastBitInterrupt in a few more places in Process WaitForEvent & friends. <rdar://problem/10792425> llvm-svn: 160903
2012-07-28 07:57:19 +08:00
event_explanation = "<user interrupt>";
Fixed a bug that caused the Process not to rebroadcast the fact that a process exited while running a thread plan. For example, if a user types the expression expr (void)exit(0) then the process terminates but LLDB does not notify listeners like Xcode that this occurred. <rdar://problem/11845155> llvm-svn: 160077
2012-07-12 05:31:24 +08:00
break;
Moved the code in ClangUserExpression that set up & ran the thread plan with timeouts, and restarting with all threads into a utility function in Process. This required a bunch of renaming. Added a ThreadPlanCallUserExpression that differs from ThreadPlanCallFunction in that it holds onto a shared pointer to its ClangUserExpression so that can't go away before the thread plan is done using it. Fixed the stop message when you hit a breakpoint while running a user expression so it is more obvious what has happened. llvm-svn: 120386
2010-11-30 10:22:11 +08:00
}
Added an lldb_private & equivalent SB API to send an AsyncInterrupt to the event loop. Convert from calling Halt in the lldb Driver.cpp's input reader's sigint handler to sending this AsyncInterrupt so it can be handled in the event loop. If you are attaching and get an async interrupt, abort the attach attempt. Also remember to destroy the process if get interrupted while attaching. Getting this to work also required handing the eBroadcastBitInterrupt in a few more places in Process WaitForEvent & friends. <rdar://problem/10792425> llvm-svn: 160903
2012-07-28 07:57:19 +08:00
else
Add more logging. Try to handle the case where "Halt" fails. This is kind of a losing game in the end, if we can't halt the target, it is not clear what we can do but keep trying... llvm-svn: 124017
2011-01-22 09:30:53 +08:00
{
Added an lldb_private & equivalent SB API to send an AsyncInterrupt to the event loop. Convert from calling Halt in the lldb Driver.cpp's input reader's sigint handler to sending this AsyncInterrupt so it can be handled in the event loop. If you are attaching and get an async interrupt, abort the attach attempt. Also remember to destroy the process if get interrupted while attaching. Getting this to work also required handing the eBroadcastBitInterrupt in a few more places in Process WaitForEvent & friends. <rdar://problem/10792425> llvm-svn: 160903
2012-07-28 07:57:19 +08:00
const Process::ProcessEventData *event_data = Process::ProcessEventData::GetEventDataFromEvent (event_sp.get());
if (!event_data)
{
event_explanation = "<no event data>";
break;
}
Fixed a bug that caused the Process not to rebroadcast the fact that a process exited while running a thread plan. For example, if a user types the expression expr (void)exit(0) then the process terminates but LLDB does not notify listeners like Xcode that this occurred. <rdar://problem/11845155> llvm-svn: 160077
2012-07-12 05:31:24 +08:00
Added an lldb_private & equivalent SB API to send an AsyncInterrupt to the event loop. Convert from calling Halt in the lldb Driver.cpp's input reader's sigint handler to sending this AsyncInterrupt so it can be handled in the event loop. If you are attaching and get an async interrupt, abort the attach attempt. Also remember to destroy the process if get interrupted while attaching. Getting this to work also required handing the eBroadcastBitInterrupt in a few more places in Process WaitForEvent & friends. <rdar://problem/10792425> llvm-svn: 160903
2012-07-28 07:57:19 +08:00
Process *process = event_data->GetProcessSP().get();
if (!process)
Fixed a bug that caused the Process not to rebroadcast the fact that a process exited while running a thread plan. For example, if a user types the expression expr (void)exit(0) then the process terminates but LLDB does not notify listeners like Xcode that this occurred. <rdar://problem/11845155> llvm-svn: 160077
2012-07-12 05:31:24 +08:00
{
Added an lldb_private & equivalent SB API to send an AsyncInterrupt to the event loop. Convert from calling Halt in the lldb Driver.cpp's input reader's sigint handler to sending this AsyncInterrupt so it can be handled in the event loop. If you are attaching and get an async interrupt, abort the attach attempt. Also remember to destroy the process if get interrupted while attaching. Getting this to work also required handing the eBroadcastBitInterrupt in a few more places in Process WaitForEvent & friends. <rdar://problem/10792425> llvm-svn: 160903
2012-07-28 07:57:19 +08:00
event_explanation = "<no process>";
break;
Fixed a bug that caused the Process not to rebroadcast the fact that a process exited while running a thread plan. For example, if a user types the expression expr (void)exit(0) then the process terminates but LLDB does not notify listeners like Xcode that this occurred. <rdar://problem/11845155> llvm-svn: 160077
2012-07-12 05:31:24 +08:00
}
Added an lldb_private & equivalent SB API to send an AsyncInterrupt to the event loop. Convert from calling Halt in the lldb Driver.cpp's input reader's sigint handler to sending this AsyncInterrupt so it can be handled in the event loop. If you are attaching and get an async interrupt, abort the attach attempt. Also remember to destroy the process if get interrupted while attaching. Getting this to work also required handing the eBroadcastBitInterrupt in a few more places in Process WaitForEvent & friends. <rdar://problem/10792425> llvm-svn: 160903
2012-07-28 07:57:19 +08:00
ThreadList &thread_list = process->GetThreadList();
Fixed a bug that caused the Process not to rebroadcast the fact that a process exited while running a thread plan. For example, if a user types the expression expr (void)exit(0) then the process terminates but LLDB does not notify listeners like Xcode that this occurred. <rdar://problem/11845155> llvm-svn: 160077
2012-07-12 05:31:24 +08:00
Added an lldb_private & equivalent SB API to send an AsyncInterrupt to the event loop. Convert from calling Halt in the lldb Driver.cpp's input reader's sigint handler to sending this AsyncInterrupt so it can be handled in the event loop. If you are attaching and get an async interrupt, abort the attach attempt. Also remember to destroy the process if get interrupted while attaching. Getting this to work also required handing the eBroadcastBitInterrupt in a few more places in Process WaitForEvent & friends. <rdar://problem/10792425> llvm-svn: 160903
2012-07-28 07:57:19 +08:00
uint32_t num_threads = thread_list.GetSize();
uint32_t thread_index;
ts.Printf("<%u threads> ", num_threads);
Fixed a bug that caused the Process not to rebroadcast the fact that a process exited while running a thread plan. For example, if a user types the expression expr (void)exit(0) then the process terminates but LLDB does not notify listeners like Xcode that this occurred. <rdar://problem/11845155> llvm-svn: 160077
2012-07-12 05:31:24 +08:00
Added an lldb_private & equivalent SB API to send an AsyncInterrupt to the event loop. Convert from calling Halt in the lldb Driver.cpp's input reader's sigint handler to sending this AsyncInterrupt so it can be handled in the event loop. If you are attaching and get an async interrupt, abort the attach attempt. Also remember to destroy the process if get interrupted while attaching. Getting this to work also required handing the eBroadcastBitInterrupt in a few more places in Process WaitForEvent & friends. <rdar://problem/10792425> llvm-svn: 160903
2012-07-28 07:57:19 +08:00
for (thread_index = 0;
thread_index < num_threads;
++thread_index)
Fixed a bug that caused the Process not to rebroadcast the fact that a process exited while running a thread plan. For example, if a user types the expression expr (void)exit(0) then the process terminates but LLDB does not notify listeners like Xcode that this occurred. <rdar://problem/11845155> llvm-svn: 160077
2012-07-12 05:31:24 +08:00
{
Added an lldb_private & equivalent SB API to send an AsyncInterrupt to the event loop. Convert from calling Halt in the lldb Driver.cpp's input reader's sigint handler to sending this AsyncInterrupt so it can be handled in the event loop. If you are attaching and get an async interrupt, abort the attach attempt. Also remember to destroy the process if get interrupted while attaching. Getting this to work also required handing the eBroadcastBitInterrupt in a few more places in Process WaitForEvent & friends. <rdar://problem/10792425> llvm-svn: 160903
2012-07-28 07:57:19 +08:00
Thread *thread = thread_list.GetThreadAtIndex(thread_index).get();
if (!thread)
{
ts.Printf("<?> ");
continue;
}
Resolve printf formatting warnings on Linux: - use macros from inttypes.h for format strings instead of OS-specific types Patch from Matt Kopec! llvm-svn: 168945
2012-11-30 05:49:15 +08:00
ts.Printf("<0x%4.4" PRIx64 " ", thread->GetID());
Added an lldb_private & equivalent SB API to send an AsyncInterrupt to the event loop. Convert from calling Halt in the lldb Driver.cpp's input reader's sigint handler to sending this AsyncInterrupt so it can be handled in the event loop. If you are attaching and get an async interrupt, abort the attach attempt. Also remember to destroy the process if get interrupted while attaching. Getting this to work also required handing the eBroadcastBitInterrupt in a few more places in Process WaitForEvent & friends. <rdar://problem/10792425> llvm-svn: 160903
2012-07-28 07:57:19 +08:00
RegisterContext *register_context = thread->GetRegisterContext().get();
if (register_context)
Resolve printf formatting warnings on Linux: - use macros from inttypes.h for format strings instead of OS-specific types Patch from Matt Kopec! llvm-svn: 168945
2012-11-30 05:49:15 +08:00
ts.Printf("[ip 0x%" PRIx64 "] ", register_context->GetPC());
Added an lldb_private & equivalent SB API to send an AsyncInterrupt to the event loop. Convert from calling Halt in the lldb Driver.cpp's input reader's sigint handler to sending this AsyncInterrupt so it can be handled in the event loop. If you are attaching and get an async interrupt, abort the attach attempt. Also remember to destroy the process if get interrupted while attaching. Getting this to work also required handing the eBroadcastBitInterrupt in a few more places in Process WaitForEvent & friends. <rdar://problem/10792425> llvm-svn: 160903
2012-07-28 07:57:19 +08:00
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(">");
Fixed a bug that caused the Process not to rebroadcast the fact that a process exited while running a thread plan. For example, if a user types the expression expr (void)exit(0) then the process terminates but LLDB does not notify listeners like Xcode that this occurred. <rdar://problem/11845155> llvm-svn: 160077
2012-07-12 05:31:24 +08:00
}
Added an lldb_private & equivalent SB API to send an AsyncInterrupt to the event loop. Convert from calling Halt in the lldb Driver.cpp's input reader's sigint handler to sending this AsyncInterrupt so it can be handled in the event loop. If you are attaching and get an async interrupt, abort the attach attempt. Also remember to destroy the process if get interrupted while attaching. Getting this to work also required handing the eBroadcastBitInterrupt in a few more places in Process WaitForEvent & friends. <rdar://problem/10792425> llvm-svn: 160903
2012-07-28 07:57:19 +08:00
event_explanation = ts.GetData();
Add more logging. Try to handle the case where "Halt" fails. This is kind of a losing game in the end, if we can't halt the target, it is not clear what we can do but keep trying... llvm-svn: 124017
2011-01-22 09:30:53 +08:00
}
Fixed a bug that caused the Process not to rebroadcast the fact that a process exited while running a thread plan. For example, if a user types the expression expr (void)exit(0) then the process terminates but LLDB does not notify listeners like Xcode that this occurred. <rdar://problem/11845155> llvm-svn: 160077
2012-07-12 05:31:24 +08:00
} while (0);
Rework the RunThreadPlan event handling to use Event Hijacking not stopping the event thread. Also clarify the logic of the function. llvm-svn: 125083
2011-02-08 13:20:59 +08:00
Added an lldb_private & equivalent SB API to send an AsyncInterrupt to the event loop. Convert from calling Halt in the lldb Driver.cpp's input reader's sigint handler to sending this AsyncInterrupt so it can be handled in the event loop. If you are attaching and get an async interrupt, abort the attach attempt. Also remember to destroy the process if get interrupted while attaching. Getting this to work also required handing the eBroadcastBitInterrupt in a few more places in Process WaitForEvent & friends. <rdar://problem/10792425> llvm-svn: 160903
2012-07-28 07:57:19 +08:00
if (event_explanation)
log->Printf("Process::RunThreadPlan(): execution interrupted: %s %s", s.GetData(), event_explanation);
Fix a bunch of places where we were calling log->Printf to put CStrings. llvm-svn: 137164
2011-08-10 06:24:33 +08:00
else
Added an lldb_private & equivalent SB API to send an AsyncInterrupt to the event loop. Convert from calling Halt in the lldb Driver.cpp's input reader's sigint handler to sending this AsyncInterrupt so it can be handled in the event loop. If you are attaching and get an async interrupt, abort the attach attempt. Also remember to destroy the process if get interrupted while attaching. Getting this to work also required handing the eBroadcastBitInterrupt in a few more places in Process WaitForEvent & friends. <rdar://problem/10792425> llvm-svn: 160903
2012-07-28 07:57:19 +08:00
log->Printf("Process::RunThreadPlan(): execution interrupted: %s", s.GetData());
}
Separated the "expr --unwind-on-error" behavior into two parts, actual errors (i.e. crashes) which continue to be controlled by the --unwind-on-error flag, and --ignore-breakpoint which separately controls behavior when a called function hits a breakpoint. For breakpoints, we don't unwind, we either stop, or ignore the breakpoint, which makes more sense. Also make both these behaviors globally settable through "settings set". Also handle the case where a breakpoint command calls code that ends up re-hitting the breakpoint. We were recursing and crashing. Now we just stop without calling the second command. <rdar://problem/12986644> <rdar://problem/9119325> llvm-svn: 172503
2013-01-15 10:47:48 +08:00
if (should_unwind && thread_plan_sp)
Added an lldb_private & equivalent SB API to send an AsyncInterrupt to the event loop. Convert from calling Halt in the lldb Driver.cpp's input reader's sigint handler to sending this AsyncInterrupt so it can be handled in the event loop. If you are attaching and get an async interrupt, abort the attach attempt. Also remember to destroy the process if get interrupted while attaching. Getting this to work also required handing the eBroadcastBitInterrupt in a few more places in Process WaitForEvent & friends. <rdar://problem/10792425> llvm-svn: 160903
2012-07-28 07:57:19 +08:00
{
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());
Fixed a bug that caused the Process not to rebroadcast the fact that a process exited while running a thread plan. For example, if a user types the expression expr (void)exit(0) then the process terminates but LLDB does not notify listeners like Xcode that this occurred. <rdar://problem/11845155> llvm-svn: 160077
2012-07-12 05:31:24 +08:00
}
}
else if (return_value == eExecutionSetupError)
{
if (log)
log->PutCString("Process::RunThreadPlan(): execution set up error.");
Rework the RunThreadPlan event handling to use Event Hijacking not stopping the event thread. Also clarify the logic of the function. llvm-svn: 125083
2011-02-08 13:20:59 +08:00
Separated the "expr --unwind-on-error" behavior into two parts, actual errors (i.e. crashes) which continue to be controlled by the --unwind-on-error flag, and --ignore-breakpoint which separately controls behavior when a called function hits a breakpoint. For breakpoints, we don't unwind, we either stop, or ignore the breakpoint, which makes more sense. Also make both these behaviors globally settable through "settings set". Also handle the case where a breakpoint command calls code that ends up re-hitting the breakpoint. We were recursing and crashing. Now we just stop without calling the second command. <rdar://problem/12986644> <rdar://problem/9119325> llvm-svn: 172503
2013-01-15 10:47:48 +08:00
if (unwind_on_error && thread_plan_sp)
Moved the code in ClangUserExpression that set up & ran the thread plan with timeouts, and restarting with all threads into a utility function in Process. This required a bunch of renaming. Added a ThreadPlanCallUserExpression that differs from ThreadPlanCallFunction in that it holds onto a shared pointer to its ClangUserExpression so that can't go away before the thread plan is done using it. Fixed the stop message when you hit a breakpoint while running a user expression so it is more obvious what has happened. llvm-svn: 120386
2010-11-30 10:22:11 +08:00
{
Converted the lldb_private::Process over to use the intrusive shared pointers. Changed the ExecutionContext over to use shared pointers for the target, process, thread and frame since these objects can easily go away at any time and any object that was holding onto an ExecutionContext was running the risk of using a bad object. Now that the shared pointers for target, process, thread and frame are just a single pointer (they all use the instrusive shared pointers) the execution context is much safer and still the same size. Made the shared pointers in the the ExecutionContext class protected and made accessors for all of the various ways to get at the pointers, references, and shared pointers. llvm-svn: 140298
2011-09-22 12:58:26 +08:00
thread->DiscardThreadPlansUpToPlan (thread_plan_sp);
Move the handling of breakpoint conditions from the Private event loop to the StopInfoBreakpoint::DoActions, which happens as the event is removed. Also use the return value of asynchronous breakpoint callbacks, they get checked before, and override the breakpoint conditions. Added ProcessModInfo class, to unify "stop_id generation" and "memory modification generation", and use where needed. llvm-svn: 137102
2011-08-09 10:12:22 +08:00
thread_plan_sp->SetPrivate (orig_plan_private);
Moved the code in ClangUserExpression that set up & ran the thread plan with timeouts, and restarting with all threads into a utility function in Process. This required a bunch of renaming. Added a ThreadPlanCallUserExpression that differs from ThreadPlanCallFunction in that it holds onto a shared pointer to its ClangUserExpression so that can't go away before the thread plan is done using it. Fixed the stop message when you hit a breakpoint while running a user expression so it is more obvious what has happened. llvm-svn: 120386
2010-11-30 10:22:11 +08:00
}
Fixed a bug that caused the Process not to rebroadcast the fact that a process exited while running a thread plan. For example, if a user types the expression expr (void)exit(0) then the process terminates but LLDB does not notify listeners like Xcode that this occurred. <rdar://problem/11845155> llvm-svn: 160077
2012-07-12 05:31:24 +08:00
}
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;
}
The run all threads timeout in RunThreadPlan should respect the user timeout, not be arbitrarily 10 seconds (which was too long anyway...) Also added some logging to RunThreadPlan and made others more regular. llvm-svn: 154708
2012-04-14 07:09:49 +08:00
else
{
if (log)
Fixed a bug that caused the Process not to rebroadcast the fact that a process exited while running a thread plan. For example, if a user types the expression expr (void)exit(0) then the process terminates but LLDB does not notify listeners like Xcode that this occurred. <rdar://problem/11845155> llvm-svn: 160077
2012-07-12 05:31:24 +08:00
log->PutCString("Process::RunThreadPlan(): thread plan stopped in mid course");
Separated the "expr --unwind-on-error" behavior into two parts, actual errors (i.e. crashes) which continue to be controlled by the --unwind-on-error flag, and --ignore-breakpoint which separately controls behavior when a called function hits a breakpoint. For breakpoints, we don't unwind, we either stop, or ignore the breakpoint, which makes more sense. Also make both these behaviors globally settable through "settings set". Also handle the case where a breakpoint command calls code that ends up re-hitting the breakpoint. We were recursing and crashing. Now we just stop without calling the second command. <rdar://problem/12986644> <rdar://problem/9119325> llvm-svn: 172503
2013-01-15 10:47:48 +08:00
if (unwind_on_error && thread_plan_sp)
Fixed a bug that caused the Process not to rebroadcast the fact that a process exited while running a thread plan. For example, if a user types the expression expr (void)exit(0) then the process terminates but LLDB does not notify listeners like Xcode that this occurred. <rdar://problem/11845155> llvm-svn: 160077
2012-07-12 05:31:24 +08:00
{
if (log)
Separated the "expr --unwind-on-error" behavior into two parts, actual errors (i.e. crashes) which continue to be controlled by the --unwind-on-error flag, and --ignore-breakpoint which separately controls behavior when a called function hits a breakpoint. For breakpoints, we don't unwind, we either stop, or ignore the breakpoint, which makes more sense. Also make both these behaviors globally settable through "settings set". Also handle the case where a breakpoint command calls code that ends up re-hitting the breakpoint. We were recursing and crashing. Now we just stop without calling the second command. <rdar://problem/12986644> <rdar://problem/9119325> llvm-svn: 172503
2013-01-15 10:47:48 +08:00
log->PutCString("Process::RunThreadPlan(): discarding thread plan 'cause unwind_on_error is set.");
Fixed a bug that caused the Process not to rebroadcast the fact that a process exited while running a thread plan. For example, if a user types the expression expr (void)exit(0) then the process terminates but LLDB does not notify listeners like Xcode that this occurred. <rdar://problem/11845155> llvm-svn: 160077
2012-07-12 05:31:24 +08:00
thread->DiscardThreadPlansUpToPlan (thread_plan_sp);
thread_plan_sp->SetPrivate (orig_plan_private);
}
The run all threads timeout in RunThreadPlan should respect the user timeout, not be arbitrarily 10 seconds (which was too long anyway...) Also added some logging to RunThreadPlan and made others more regular. llvm-svn: 154708
2012-04-14 07:09:49 +08:00
}
Moved the code in ClangUserExpression that set up & ran the thread plan with timeouts, and restarting with all threads into a utility function in Process. This required a bunch of renaming. Added a ThreadPlanCallUserExpression that differs from ThreadPlanCallFunction in that it holds onto a shared pointer to its ClangUserExpression so that can't go away before the thread plan is done using it. Fixed the stop message when you hit a breakpoint while running a user expression so it is more obvious what has happened. llvm-svn: 120386
2010-11-30 10:22:11 +08:00
}
Fixed a bug that caused the Process not to rebroadcast the fact that a process exited while running a thread plan. For example, if a user types the expression expr (void)exit(0) then the process terminates but LLDB does not notify listeners like Xcode that this occurred. <rdar://problem/11845155> llvm-svn: 160077
2012-07-12 05:31:24 +08:00
// 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)
Rework the RunThreadPlan event handling to use Event Hijacking not stopping the event thread. Also clarify the logic of the function. llvm-svn: 125083
2011-02-08 13:20:59 +08:00
{
Fixed a bug that caused the Process not to rebroadcast the fact that a process exited while running a thread plan. For example, if a user types the expression expr (void)exit(0) then the process terminates but LLDB does not notify listeners like Xcode that this occurred. <rdar://problem/11845155> llvm-svn: 160077
2012-07-12 05:31:24 +08:00
exe_ctx.SetFrameSP (thread->GetFrameWithStackID (ctx_frame_id));
Rework the RunThreadPlan event handling to use Event Hijacking not stopping the event thread. Also clarify the logic of the function. llvm-svn: 125083
2011-02-08 13:20:59 +08:00
}
Fixed a bug that caused the Process not to rebroadcast the fact that a process exited while running a thread plan. For example, if a user types the expression expr (void)exit(0) then the process terminates but LLDB does not notify listeners like Xcode that this occurred. <rdar://problem/11845155> llvm-svn: 160077
2012-07-12 05:31:24 +08:00
// 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)
Rework the RunThreadPlan event handling to use Event Hijacking not stopping the event thread. Also clarify the logic of the function. llvm-svn: 125083
2011-02-08 13:20:59 +08:00
{
Fixed a bug that caused the Process not to rebroadcast the fact that a process exited while running a thread plan. For example, if a user types the expression expr (void)exit(0) then the process terminates but LLDB does not notify listeners like Xcode that this occurred. <rdar://problem/11845155> llvm-svn: 160077
2012-07-12 05:31:24 +08:00
if (GetThreadList().SetSelectedThreadByIndexID (selected_tid) && selected_stack_id.IsValid())
Rework the RunThreadPlan event handling to use Event Hijacking not stopping the event thread. Also clarify the logic of the function. llvm-svn: 125083
2011-02-08 13:20:59 +08:00
{
Fixed a bug that caused the Process not to rebroadcast the fact that a process exited while running a thread plan. For example, if a user types the expression expr (void)exit(0) then the process terminates but LLDB does not notify listeners like Xcode that this occurred. <rdar://problem/11845155> llvm-svn: 160077
2012-07-12 05:31:24 +08:00
// We were able to restore the selected thread, now restore the frame:
StackFrameSP old_frame_sp = GetThreadList().GetSelectedThread()->GetFrameWithStackID(selected_stack_id);
if (old_frame_sp)
GetThreadList().GetSelectedThread()->SetSelectedFrame(old_frame_sp.get());
Rework the RunThreadPlan event handling to use Event Hijacking not stopping the event thread. Also clarify the logic of the function. llvm-svn: 125083
2011-02-08 13:20:59 +08:00
}
}
}
Moved the code in ClangUserExpression that set up & ran the thread plan with timeouts, and restarting with all threads into a utility function in Process. This required a bunch of renaming. Added a ThreadPlanCallUserExpression that differs from ThreadPlanCallFunction in that it holds onto a shared pointer to its ClangUserExpression so that can't go away before the thread plan is done using it. Fixed the stop message when you hit a breakpoint while running a user expression so it is more obvious what has happened. llvm-svn: 120386
2010-11-30 10:22:11 +08:00
Fixed a bug that caused the Process not to rebroadcast the fact that a process exited while running a thread plan. For example, if a user types the expression expr (void)exit(0) then the process terminates but LLDB does not notify listeners like Xcode that this occurred. <rdar://problem/11845155> llvm-svn: 160077
2012-07-12 05:31:24 +08:00
// If the process exited during the run of the thread plan, notify everyone.
Moved the code in ClangUserExpression that set up & ran the thread plan with timeouts, and restarting with all threads into a utility function in Process. This required a bunch of renaming. Added a ThreadPlanCallUserExpression that differs from ThreadPlanCallFunction in that it holds onto a shared pointer to its ClangUserExpression so that can't go away before the thread plan is done using it. Fixed the stop message when you hit a breakpoint while running a user expression so it is more obvious what has happened. llvm-svn: 120386
2010-11-30 10:22:11 +08:00
Fixed a bug that caused the Process not to rebroadcast the fact that a process exited while running a thread plan. For example, if a user types the expression expr (void)exit(0) then the process terminates but LLDB does not notify listeners like Xcode that this occurred. <rdar://problem/11845155> llvm-svn: 160077
2012-07-12 05:31:24 +08:00
if (event_to_broadcast_sp)
Moved the code in ClangUserExpression that set up & ran the thread plan with timeouts, and restarting with all threads into a utility function in Process. This required a bunch of renaming. Added a ThreadPlanCallUserExpression that differs from ThreadPlanCallFunction in that it holds onto a shared pointer to its ClangUserExpression so that can't go away before the thread plan is done using it. Fixed the stop message when you hit a breakpoint while running a user expression so it is more obvious what has happened. llvm-svn: 120386
2010-11-30 10:22:11 +08:00
{
Fixed a bug that caused the Process not to rebroadcast the fact that a process exited while running a thread plan. For example, if a user types the expression expr (void)exit(0) then the process terminates but LLDB does not notify listeners like Xcode that this occurred. <rdar://problem/11845155> llvm-svn: 160077
2012-07-12 05:31:24 +08:00
if (log)
log->PutCString("Process::RunThreadPlan(): rebroadcasting event.");
BroadcastEvent(event_to_broadcast_sp);
Moved the code in ClangUserExpression that set up & ran the thread plan with timeouts, and restarting with all threads into a utility function in Process. This required a bunch of renaming. Added a ThreadPlanCallUserExpression that differs from ThreadPlanCallFunction in that it holds onto a shared pointer to its ClangUserExpression so that can't go away before the thread plan is done using it. Fixed the stop message when you hit a breakpoint while running a user expression so it is more obvious what has happened. llvm-svn: 120386
2010-11-30 10:22:11 +08:00
}
return return_value;
}
const char *
Process::ExecutionResultAsCString (ExecutionResults result)
{
const char *result_name;
switch (result)
{
Fixed the LLDB build so that we can have private types, private enums and public types and public enums. This was done to keep the SWIG stuff from parsing all sorts of enums and types that weren't needed, and allows us to abstract our API better. llvm-svn: 128239
2011-03-25 05:19:54 +08:00
case eExecutionCompleted:
Moved the code in ClangUserExpression that set up & ran the thread plan with timeouts, and restarting with all threads into a utility function in Process. This required a bunch of renaming. Added a ThreadPlanCallUserExpression that differs from ThreadPlanCallFunction in that it holds onto a shared pointer to its ClangUserExpression so that can't go away before the thread plan is done using it. Fixed the stop message when you hit a breakpoint while running a user expression so it is more obvious what has happened. llvm-svn: 120386
2010-11-30 10:22:11 +08:00
result_name = "eExecutionCompleted";
break;
Fixed the LLDB build so that we can have private types, private enums and public types and public enums. This was done to keep the SWIG stuff from parsing all sorts of enums and types that weren't needed, and allows us to abstract our API better. llvm-svn: 128239
2011-03-25 05:19:54 +08:00
case eExecutionDiscarded:
Moved the code in ClangUserExpression that set up & ran the thread plan with timeouts, and restarting with all threads into a utility function in Process. This required a bunch of renaming. Added a ThreadPlanCallUserExpression that differs from ThreadPlanCallFunction in that it holds onto a shared pointer to its ClangUserExpression so that can't go away before the thread plan is done using it. Fixed the stop message when you hit a breakpoint while running a user expression so it is more obvious what has happened. llvm-svn: 120386
2010-11-30 10:22:11 +08:00
result_name = "eExecutionDiscarded";
break;
Fixed the LLDB build so that we can have private types, private enums and public types and public enums. This was done to keep the SWIG stuff from parsing all sorts of enums and types that weren't needed, and allows us to abstract our API better. llvm-svn: 128239
2011-03-25 05:19:54 +08:00
case eExecutionInterrupted:
Moved the code in ClangUserExpression that set up & ran the thread plan with timeouts, and restarting with all threads into a utility function in Process. This required a bunch of renaming. Added a ThreadPlanCallUserExpression that differs from ThreadPlanCallFunction in that it holds onto a shared pointer to its ClangUserExpression so that can't go away before the thread plan is done using it. Fixed the stop message when you hit a breakpoint while running a user expression so it is more obvious what has happened. llvm-svn: 120386
2010-11-30 10:22:11 +08:00
result_name = "eExecutionInterrupted";
break;
Separated the "expr --unwind-on-error" behavior into two parts, actual errors (i.e. crashes) which continue to be controlled by the --unwind-on-error flag, and --ignore-breakpoint which separately controls behavior when a called function hits a breakpoint. For breakpoints, we don't unwind, we either stop, or ignore the breakpoint, which makes more sense. Also make both these behaviors globally settable through "settings set". Also handle the case where a breakpoint command calls code that ends up re-hitting the breakpoint. We were recursing and crashing. Now we just stop without calling the second command. <rdar://problem/12986644> <rdar://problem/9119325> llvm-svn: 172503
2013-01-15 10:47:48 +08:00
case eExecutionHitBreakpoint:
result_name = "eExecutionHitBreakpoint";
break;
Fixed the LLDB build so that we can have private types, private enums and public types and public enums. This was done to keep the SWIG stuff from parsing all sorts of enums and types that weren't needed, and allows us to abstract our API better. llvm-svn: 128239
2011-03-25 05:19:54 +08:00
case eExecutionSetupError:
Moved the code in ClangUserExpression that set up & ran the thread plan with timeouts, and restarting with all threads into a utility function in Process. This required a bunch of renaming. Added a ThreadPlanCallUserExpression that differs from ThreadPlanCallFunction in that it holds onto a shared pointer to its ClangUserExpression so that can't go away before the thread plan is done using it. Fixed the stop message when you hit a breakpoint while running a user expression so it is more obvious what has happened. llvm-svn: 120386
2010-11-30 10:22:11 +08:00
result_name = "eExecutionSetupError";
break;
Fixed the LLDB build so that we can have private types, private enums and public types and public enums. This was done to keep the SWIG stuff from parsing all sorts of enums and types that weren't needed, and allows us to abstract our API better. llvm-svn: 128239
2011-03-25 05:19:54 +08:00
case eExecutionTimedOut:
Moved the code in ClangUserExpression that set up & ran the thread plan with timeouts, and restarting with all threads into a utility function in Process. This required a bunch of renaming. Added a ThreadPlanCallUserExpression that differs from ThreadPlanCallFunction in that it holds onto a shared pointer to its ClangUserExpression so that can't go away before the thread plan is done using it. Fixed the stop message when you hit a breakpoint while running a user expression so it is more obvious what has happened. llvm-svn: 120386
2010-11-30 10:22:11 +08:00
result_name = "eExecutionTimedOut";
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();
Fixed an issue with the pthread_setspecific() where we weren't NULL-ing out the thread specific data and were destroying the thread specfic data more than once. Also added the ability to ask a lldb::StateType if it is stopped with an additional paramter of "must_exist" which means that the state must be a stopped state for a process that still exists. This means that eStateExited and eStateUnloaded will no longer return true if "must_exist" is set to true. llvm-svn: 144875
2011-11-17 09:23:07 +08:00
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();
Resolve printf formatting warnings on Linux: - use macros from inttypes.h for format strings instead of OS-specific types Patch from Matt Kopec! llvm-svn: 168945
2012-11-30 05:49:15 +08:00
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
Resolve printf formatting warnings on Linux: - use macros from inttypes.h for format strings instead of OS-specific types Patch from Matt Kopec! llvm-svn: 168945
2012-11-30 05:49:15 +08:00
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
{
Resolve printf formatting warnings on Linux: - use macros from inttypes.h for format strings instead of OS-specific types Patch from Matt Kopec! llvm-svn: 168945
2012-11-30 05:49:15 +08:00
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;
Fixed a few places where we were doing: uint32_t size = ThreadList.GetSize(); for (i=0; i < size; ++i) without grabbing the thread list mutex. llvm-svn: 163541
2012-09-11 04:50:15 +08:00
Mutex::Locker locker (GetThreadList().GetMutex());
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
const size_t num_threads = GetThreadList().GetSize();
for (uint32_t i = 0; i < num_threads; i++)
{
Thread *thread = GetThreadList().GetThreadAtIndex(i).get();
if (thread)
{
if (only_threads_with_stop_reason)
{
Patch from Matt Kopec <matt.kopec@intel.com> to fix the problem that if two breakpoints were set on consecutive addresses, the continue from the first breakpoint would skip the second. llvm-svn: 166000
2012-10-16 08:09:33 +08:00
StopInfoSP stop_info_sp = thread->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->GetStatus (strm,
start_frame,
num_frames,
num_frames_with_source);
++num_thread_infos_dumped;
}
}
return num_thread_infos_dumped;
}
For stepping performance I added the ability to outlaw all memory accesseses to the __PAGEZERO segment on darwin. The dynamic loader now correctly doesn't slide __PAGEZERO and it also registers it as an invalid region of memory. This allows us to not make any memory requests from the local or remote debug session for any addresses in this region. Stepping performance can improve when uninitialized local variables that point to locations in __PAGEZERO are attempted to be read from memory as we won't even make the memory read or write request. llvm-svn: 151128
2012-02-22 12:37:26 +08:00
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());
}
We sometimes need to be able to call functions (via Process::RunThreadPlan) from code run on the private state thread. To do that we have to spin up a temporary "private state thread" that will respond to events from the lower level process plugins. This check-in should work to do that, but it is still buggy. However, if you don't call functions on the private state thread, these changes make no difference. This patch also moves the code in the AppleObjCRuntime step-through-trampoline handler that might call functions (in the case where the debug server doesn't support the memory allocate/deallocate packet) out to a safe place to do that call. llvm-svn: 154230
2012-04-07 08:00:41 +08:00
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();
}
For stepping performance I added the ability to outlaw all memory accesseses to the __PAGEZERO segment on darwin. The dynamic loader now correctly doesn't slide __PAGEZERO and it also registers it as an invalid region of memory. This allows us to not make any memory requests from the local or remote debug session for any addresses in this region. Stepping performance can improve when uninitialized local variables that point to locations in __PAGEZERO are attempted to be read from memory as we won't even make the memory read or write request. llvm-svn: 151128
2012-02-22 12:37:26 +08:00
<rdar://problem/11386214> <rdar://problem/11455913> "target symbol add" should flush the cached frames "register write" should flush the thread state in case registers modifications change stack llvm-svn: 157042
2012-05-18 10:38:05 +08:00
void
Process::Flush ()
{
m_thread_list.Flush();
}
<rdar://problem/12649160> Added the ability to debug through your process exec'ing itself to the same architecture. llvm-svn: 169340
2012-12-05 08:16:59 +08:00
void
Process::DidExec ()
{
Target &target = GetTarget();
target.CleanupProcess ();
ModuleList unloaded_modules (target.GetImages());
target.ModulesDidUnload (unloaded_modules);
target.GetSectionLoadList().Clear();
m_dynamic_checkers_ap.reset();
m_abi_sp.reset();
m_os_ap.reset();
m_dyld_ap.reset();
m_image_tokens.clear();
m_allocated_memory_cache.Clear();
m_language_runtimes.clear();
DoDidExec();
CompleteAttach ();
}