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

6576 lines
240 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 Clang-tidy modernize-use-override warnings in source/Target; other minor fixes. llvm-svn: 251134
2015-10-24 02:39:37 +08:00
// C Includes
// C++ Includes
// Other libraries and framework includes
// Project includes
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/Breakpoint/StoppointCallbackContext.h"
#include "lldb/Breakpoint/BreakpointLocation.h"
#include "lldb/Core/Event.h"
#include "lldb/Core/Debugger.h"
#include "lldb/Core/Log.h"
<rdar://problem/11757916> Make breakpoint setting by file and line much more efficient by only looking for inlined breakpoint locations if we are setting a breakpoint in anything but a source implementation file. Implementing this complex for a many reasons. Turns out that parsing compile units lazily had some issues with respect to how we need to do things with DWARF in .o files. So the fixes in the checkin for this makes these changes: - Add a new setting called "target.inline-breakpoint-strategy" which can be set to "never", "always", or "headers". "never" will never try and set any inlined breakpoints (fastest). "always" always looks for inlined breakpoint locations (slowest, but most accurate). "headers", which is the default setting, will only look for inlined breakpoint locations if the breakpoint is set in what are consudered to be header files, which is realy defined as "not in an implementation source file". - modify the breakpoint setting by file and line to check the current "target.inline-breakpoint-strategy" setting and act accordingly - Modify compile units to be able to get their language and other info lazily. This allows us to create compile units from the debug map and not have to fill all of the details in, and then lazily discover this information as we go on debuggging. This is needed to avoid parsing all .o files when setting breakpoints in implementation only files (no inlines). Otherwise we would need to parse the .o file, the object file (mach-o in our case) and the symbol file (DWARF in the object file) just to see what the compile unit was. - modify the "SymbolFileDWARFDebugMap" to subclass lldb_private::Module so that the virtual "GetObjectFile()" and "GetSymbolVendor()" functions can be intercepted when the .o file contenst are later lazilly needed. Prior to this fix, when we first instantiated the "SymbolFileDWARFDebugMap" class, we would also make modules, object files and symbol files for every .o file in the debug map because we needed to fix up the sections in the .o files with information that is in the executable debug map. Now we lazily do this in the DebugMapModule::GetObjectFile() Cleaned up header includes a bit as well. llvm-svn: 162860
2012-08-30 05:13:06 +08:00
#include "lldb/Core/Module.h"
Fetch module specification from remote process also Previously the remote module sepcification was fetched only from the remote platform. With this CL if we have a remote process then we ask it if it have any information from a given module. It is required because on android the dynamic linker only reports the name of the SO file and the platform can't always find it without a full path (the process can do it based on /proc/<pid>/maps). Differential revision: http://reviews.llvm.org/D8547 llvm-svn: 233061
2015-03-24 19:15:23 +08:00
#include "lldb/Core/ModuleSpec.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"
Merging the iohandler branch back into main. The many many benefits include: 1 - Input/Output/Error streams are now handled as real streams not a push style input 2 - auto completion in python embedded interpreter 3 - multi-line input for "script" and "expression" commands now allow you to edit previous/next lines using up and down arrow keys and this makes multi-line input actually a viable thing to use 4 - it is now possible to use curses to drive LLDB (please try the "gui" command) We will need to deal with and fix any buildbot failures and tests and arise now that input/output and error are correctly hooked up in all cases. llvm-svn: 200263
2014-01-28 07:43:24 +08:00
#include "lldb/Core/StreamFile.h"
This patch makes Clang-independent base classes for all the expression types that lldb currently vends. Before we had: ClangFunction ClangUtilityFunction ClangUserExpression and code all over in lldb that explicitly made Clang-based expressions. This patch adds an Expression base class, and three pure virtual implementations for the Expression kinds: FunctionCaller UtilityFunction UserExpression You can request one of these expression types from the Target using the Get<ExpressionType>ForLanguage. The Target will then consult all the registered TypeSystem plugins, and if the type system that matches the language can make an expression of that kind, it will do so and return it. Because all of the real expression types need to communicate with their ExpressionParser in a uniform way, I also added a ExpressionTypeSystemHelper class that expressions generically can vend, and a ClangExpressionHelper that encapsulates the operations that the ClangExpressionParser needs to perform on the ClangExpression types. Then each of the Clang* expression kinds constructs the appropriate helper to do what it needs. The patch also fixes a wart in the UtilityFunction that to use it you had to create a parallel FunctionCaller to actually call the function made by the UtilityFunction. Now the UtilityFunction can be asked to vend a FunctionCaller that will run its function. This cleaned up a lot of boiler plate code using UtilityFunctions. Note, in this patch all the expression types explicitly depend on the LLVM JIT and IR, and all the common JIT running code is in the FunctionCaller etc base classes. At some point we could also abstract that dependency but I don't see us adding another back end in the near term, so I'll leave that exercise till it is actually necessary. llvm-svn: 247720
2015-09-16 05:13:50 +08:00
#include "lldb/Expression/UserExpression.h"
Further reduce the header footprint of Process.h No functional change here, only deletes unnecessary headers and moves one function's body from the .h file to the .cpp. llvm-svn: 231145
2015-03-04 05:51:25 +08:00
#include "lldb/Expression/IRDynamicChecks.h"
Move ConnectionFileDescriptor to platform-specific Host directory. As part of getting ConnectionFileDescriptor working on Windows, there is going to be alot of platform specific work to be done. As a result, the implementation is moving into Host. This patch performs the code move and fixes up call-sites appropriately. Reviewed by: Greg Clayton Differential Revision: http://reviews.llvm.org/D5548 llvm-svn: 219143
2014-10-07 05:22:36 +08:00
#include "lldb/Host/ConnectionFileDescriptor.h"
Make uses of /dev/null portable across OSes. Most platforms have "/dev/null". Windows has "nul". Instead of hardcoding the string /dev/null at various places, make a constant that contains the correct value depending on the platform, and use that everywhere instead. llvm-svn: 250331
2015-10-15 05:37:36 +08:00
#include "lldb/Host/FileSystem.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"
Create a HostThread abstraction. This patch moves creates a thread abstraction that represents a thread running inside the LLDB process. This is a replacement for otherwise using lldb::thread_t, and provides a platform agnostic interface to managing these threads. Differential Revision: http://reviews.llvm.org/D5198 Reviewed by: Jim Ingham llvm-svn: 217460
2014-09-10 04:54:56 +08:00
#include "lldb/Host/HostInfo.h"
Add host layer support for pipes. Windows does support pipes, but they do so in a slightly different way. Added a Host layer which abstracts the use of pipes into a new Pipe class that everyone can use. Windows benefits include: - Being able to interrupt running processes when IO is directly hooked up - being able to interrupt long running python scripts - being able to interrupt anything based on ConnectionFileDescriptor llvm-svn: 212220
2014-07-03 05:10:39 +08:00
#include "lldb/Host/Pipe.h"
Merging the iohandler branch back into main. The many many benefits include: 1 - Input/Output/Error streams are now handled as real streams not a push style input 2 - auto completion in python embedded interpreter 3 - multi-line input for "script" and "expression" commands now allow you to edit previous/next lines using up and down arrow keys and this makes multi-line input actually a viable thing to use 4 - it is now possible to use curses to drive LLDB (please try the "gui" command) We will need to deal with and fix any buildbot failures and tests and arise now that input/output and error are correctly hooked up in all cases. llvm-svn: 200263
2014-01-28 07:43:24 +08:00
#include "lldb/Host/Terminal.h"
Create a HostThread abstraction. This patch moves creates a thread abstraction that represents a thread running inside the LLDB process. This is a replacement for otherwise using lldb::thread_t, and provides a platform agnostic interface to managing these threads. Differential Revision: http://reviews.llvm.org/D5198 Reviewed by: Jim Ingham llvm-svn: 217460
2014-09-10 04:54:56 +08:00
#include "lldb/Host/ThreadLauncher.h"
Move ConnectionFileDescriptor to platform-specific Host directory. As part of getting ConnectionFileDescriptor working on Windows, there is going to be alot of platform specific work to be done. As a result, the implementation is moving into Host. This patch performs the code move and fixes up call-sites appropriately. Reviewed by: Greg Clayton Differential Revision: http://reviews.llvm.org/D5548 llvm-svn: 219143
2014-10-07 05:22:36 +08:00
#include "lldb/Interpreter/CommandInterpreter.h"
Further reduce header footprint of Debugger.h. llvm-svn: 231202
2015-03-04 09:58:01 +08:00
#include "lldb/Interpreter/OptionValueProperties.h"
Feedback from Jim: Change the "optimized code" warning to be entirely contained within Process so that we won't be duplicating the warning message if other parts of the code want to issue the message. Change Process::PrintWarning to be a protected method - the public method will be the PrintWarningOptimization et al. Also, Have Thread::FunctionOptimizationWarning shortcut out if the warnings have been disabled so that we don't (potentially) compute parts of the SymbolContext unnecessarily. llvm-svn: 244436
2015-08-10 15:55:25 +08:00
#include "lldb/Symbol/Function.h"
Move ConnectionFileDescriptor to platform-specific Host directory. As part of getting ConnectionFileDescriptor working on Windows, there is going to be alot of platform specific work to be done. As a result, the implementation is moving into Host. This patch performs the code move and fixes up call-sites appropriately. Reviewed by: Greg Clayton Differential Revision: http://reviews.llvm.org/D5548 llvm-svn: 219143
2014-10-07 05:22:36 +08:00
#include "lldb/Symbol/Symbol.h"
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
#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"
Further reduce the header footprint of Process.h No functional change here, only deletes unnecessary headers and moves one function's body from the .h file to the .cpp. llvm-svn: 231145
2015-03-04 05:51:25 +08:00
#include "lldb/Target/InstrumentationRuntime.h"
Add support for JIT debugging on Linux using the GDB JIT interface. Patch written with Keno Fischer. llvm-svn: 202956
2014-03-05 18:12:43 +08:00
#include "lldb/Target/JITLoader.h"
Further reduce the header footprint of Process.h No functional change here, only deletes unnecessary headers and moves one function's body from the .h file to the .cpp. llvm-svn: 231145
2015-03-04 05:51:25 +08:00
#include "lldb/Target/JITLoaderList.h"
Implement ASan history threads in SB API Reviewed at http://reviews.llvm.org/D5219 and http://lists.cs.uiuc.edu/pipermail/lldb-commits/Week-of-Mon-20140901/012809.html llvm-svn: 217300
2014-09-06 09:33:13 +08:00
#include "lldb/Target/MemoryHistory.h"
Further reduce the header footprint of Process.h No functional change here, only deletes unnecessary headers and moves one function's body from the .h file to the .cpp. llvm-svn: 231145
2015-03-04 05:51:25 +08:00
#include "lldb/Target/MemoryRegionInfo.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"
Add a new system runtime plugin type - just the top level class, not any actual plugin implementation yet. <rdar://problem/15314068> llvm-svn: 194044
2013-11-05 11:57:19 +08:00
#include "lldb/Target/SystemRuntime.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"
Further reduce the header footprint of Process.h No functional change here, only deletes unnecessary headers and moves one function's body from the .h file to the .cpp. llvm-svn: 231145
2015-03-04 05:51:25 +08:00
#include "lldb/Target/UnixSignals.h"
Move some functions from source/lldb.cpp to Utility. Specifically, there were some functions for converting enums to strings and a function for matching a string using a specific matching algorithm. This moves those functions to more appropriate headers in lldb/Utility and updates references to include the new headers. llvm-svn: 232673
2015-03-19 05:31:45 +08:00
#include "lldb/Utility/NameMatches.h"
Get the breakpoint setting, and the Mac OS X DYLD trampolines and expression evaluator to handle Indirect symbols correctly. There were a couple of pieces to this. 1) When a breakpoint location finds itself pointing to an Indirect symbol, when the site for it is created it needs to resolve the symbol and actually set the site at its target. 2) Not all breakpoints want to do this (i.e. a straight address breakpoint should always set itself on the specified address, so somem machinery was needed to specify that. 3) I added some info to the break list output for indirect symbols so you could see what was happening. Also I made it clear when we re-route through re-exported symbols. 4) I moved ResolveIndirectFunction from ProcessPosix to Process since it works the exact same way on Mac OS X and the other posix systems. If we find a platform that doesn't do it this way, they can override the call in Process. 5) Fixed one bug in RunThreadPlan, if you were trying to run a thread plan after a "running" event had been broadcast, the event coalescing would cause you to miss the ThreadPlan running event. So I added a way to override the coalescing. 6) Made DynamicLoaderMacOSXDYLD::GetStepThroughTrampolinePlan handle Indirect & Re-exported symbols. <rdar://problem/15280639> llvm-svn: 198976
2014-01-11 07:46:59 +08:00
#include "Plugins/Process/Utility/InferiorCallPOSIX.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())
{
}
Fix Clang-tidy modernize-use-override warnings in source/Target; other minor fixes. llvm-svn: 251134
2015-10-24 02:39:37 +08:00
const Property *
GetPropertyAtIndex(const ExecutionContext *exe_ctx, bool will_modify, uint32_t idx) const override
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
{
Fix typos. llvm-svn: 212132
2014-07-02 05:22:11 +08:00
// When getting the value for a key from the process options, we will always
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
// 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." },
Recommitting r180831 with trivial fix - remember to return errors if you compute. llvm-svn: 180898
2013-05-02 08:27:30 +08:00
{ "detach-keeps-stopped" , OptionValue::eTypeBoolean, true, false, NULL, NULL, "If true, detach will attempt to keep the process stopped." },
Add a new target.process.memory-cache-line-size to change the size of lldb's internal memory cache chunks that are read from the remote system. For a remote connection that is especially slow, a user may need to reduce it; reading a 512 byte chunk of memory whenever a 4-byte region is requested may not be the right decision in these kinds of environments. <rdar://problem/18175117> llvm-svn: 217083
2014-09-04 06:30:54 +08:00
{ "memory-cache-line-size" , OptionValue::eTypeUInt64, false, 512, NULL, NULL, "The memory cache line size" },
Second part of indicating when the user is stopped in optimized code. The first part was in r243508 -- the extent of the UI changes in that patchset was to add "[opt]" to the frame-format when a stack frame was built with optimized code. In this change, when a stack frame built with optimization is selected, a message will be printed to the async output channel -- opt1.c was compiled with optimization - stepping may behave oddly; variables may not be available. The warning will be only be printed once per source file in a debug session. These warnings may be disabled by settings set target.process.optimization-warnings false Internally, a new Process::PrintWarning() method has been added for warnings that we want to print only once to the user. It takes a type of warning (currently only eWarningsOptimization) and an object pointer (CompileUnit*) - the warning will only be printed once for a given object pointer value. This is a bit of a prototype of this change - I think we will be tweaking it more in the future. But I wanted to land this and see how it goes. Advanced users will find these warnings unnecessary noise and will quickly disable them - but anyone who maintains a debugger knows that debugging optimized code, without realizing it, is a constant source of confusion and frustation for more typical debugger users. I imagine there will be more of these "warn once per whatever" style warnings that we will want to add in the future and we'll need to come up with a better way for enabling/disabling them. But I'm not srue what form that warning settings should take and I didn't want to code up something that we regret later, so for now I just added another process setting for this one warning. <rdar://problem/19281172> llvm-svn: 244190
2015-08-06 11:27:10 +08:00
{ "optimization-warnings" , OptionValue::eTypeBoolean, false, true, NULL, NULL, "If true, warn when stopped in code that is optimized where stepping and variable availability may not behave as expected." },
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,
Recommitting r180831 with trivial fix - remember to return errors if you compute. llvm-svn: 180898
2013-05-02 08:27:30 +08:00
ePropertyStopOnSharedLibraryEvents,
Add a new target.process.memory-cache-line-size to change the size of lldb's internal memory cache chunks that are read from the remote system. For a remote connection that is especially slow, a user may need to reduce it; reading a 512 byte chunk of memory whenever a 4-byte region is requested may not be the right decision in these kinds of environments. <rdar://problem/18175117> llvm-svn: 217083
2014-09-04 06:30:54 +08:00
ePropertyDetachKeepsStopped,
Second part of indicating when the user is stopped in optimized code. The first part was in r243508 -- the extent of the UI changes in that patchset was to add "[opt]" to the frame-format when a stack frame was built with optimized code. In this change, when a stack frame built with optimization is selected, a message will be printed to the async output channel -- opt1.c was compiled with optimization - stepping may behave oddly; variables may not be available. The warning will be only be printed once per source file in a debug session. These warnings may be disabled by settings set target.process.optimization-warnings false Internally, a new Process::PrintWarning() method has been added for warnings that we want to print only once to the user. It takes a type of warning (currently only eWarningsOptimization) and an object pointer (CompileUnit*) - the warning will only be printed once for a given object pointer value. This is a bit of a prototype of this change - I think we will be tweaking it more in the future. But I wanted to land this and see how it goes. Advanced users will find these warnings unnecessary noise and will quickly disable them - but anyone who maintains a debugger knows that debugging optimized code, without realizing it, is a constant source of confusion and frustation for more typical debugger users. I imagine there will be more of these "warn once per whatever" style warnings that we will want to add in the future and we'll need to come up with a better way for enabling/disabling them. But I'm not srue what form that warning settings should take and I didn't want to code up something that we regret later, so for now I just added another process setting for this one warning. <rdar://problem/19281172> llvm-svn: 244190
2015-08-06 11:27:10 +08:00
ePropertyMemCacheLineSize,
ePropertyWarningOptimization
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
};
Fixed an issue where if the operating system python plug-in is changed at runtime, it wouldn't cause the process to reload the new operating system plug-in, now it does. This is currently controlled by a setting: (lldb) settings set target.process.python-os-plugin-path <path> Or clearing it with: (lldb) settings clear target.process.python-os-plugin-path The process will now reload the OperatingSystem plug-in. This was implemented by: - adding the ability to set a notify callback for when an option value is changed - added the ability for the process plug-in to load the operating system plug-in on the fly - fixed bugs in the Process::GetStatus() so all threads are displayed if their thread IDs are larger than 32 bits - adding a callback in ProcessProperties to tell when the "python-os-plugin-path" is changed by the user - fixing a crasher in ProcessMachCore that happens when updating the thread list when the OS plugin is reloaded llvm-svn: 225831
2015-01-14 05:13:08 +08:00
ProcessProperties::ProcessProperties (lldb_private::Process *process) :
Properties (),
m_process (process) // Can be NULL for global ProcessProperties
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
{
Fixed an issue where if the operating system python plug-in is changed at runtime, it wouldn't cause the process to reload the new operating system plug-in, now it does. This is currently controlled by a setting: (lldb) settings set target.process.python-os-plugin-path <path> Or clearing it with: (lldb) settings clear target.process.python-os-plugin-path The process will now reload the OperatingSystem plug-in. This was implemented by: - adding the ability to set a notify callback for when an option value is changed - added the ability for the process plug-in to load the operating system plug-in on the fly - fixed bugs in the Process::GetStatus() so all threads are displayed if their thread IDs are larger than 32 bits - adding a callback in ProcessProperties to tell when the "python-os-plugin-path" is changed by the user - fixing a crasher in ProcessMachCore that happens when updating the thread list when the OS plugin is reloaded llvm-svn: 225831
2015-01-14 05:13:08 +08:00
if (process == NULL)
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
{
Fixed an issue where if the operating system python plug-in is changed at runtime, it wouldn't cause the process to reload the new operating system plug-in, now it does. This is currently controlled by a setting: (lldb) settings set target.process.python-os-plugin-path <path> Or clearing it with: (lldb) settings clear target.process.python-os-plugin-path The process will now reload the OperatingSystem plug-in. This was implemented by: - adding the ability to set a notify callback for when an option value is changed - added the ability for the process plug-in to load the operating system plug-in on the fly - fixed bugs in the Process::GetStatus() so all threads are displayed if their thread IDs are larger than 32 bits - adding a callback in ProcessProperties to tell when the "python-os-plugin-path" is changed by the user - fixing a crasher in ProcessMachCore that happens when updating the thread list when the OS plugin is reloaded llvm-svn: 225831
2015-01-14 05:13:08 +08:00
// Global process properties, set them up one time
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
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
Fixed an issue where if the operating system python plug-in is changed at runtime, it wouldn't cause the process to reload the new operating system plug-in, now it does. This is currently controlled by a setting: (lldb) settings set target.process.python-os-plugin-path <path> Or clearing it with: (lldb) settings clear target.process.python-os-plugin-path The process will now reload the OperatingSystem plug-in. This was implemented by: - adding the ability to set a notify callback for when an option value is changed - added the ability for the process plug-in to load the operating system plug-in on the fly - fixed bugs in the Process::GetStatus() so all threads are displayed if their thread IDs are larger than 32 bits - adding a callback in ProcessProperties to tell when the "python-os-plugin-path" is changed by the user - fixing a crasher in ProcessMachCore that happens when updating the thread list when the OS plugin is reloaded llvm-svn: 225831
2015-01-14 05:13:08 +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
m_collection_sp.reset (new ProcessOptionValueProperties(Process::GetGlobalProperties().get()));
Fixed an issue where if the operating system python plug-in is changed at runtime, it wouldn't cause the process to reload the new operating system plug-in, now it does. This is currently controlled by a setting: (lldb) settings set target.process.python-os-plugin-path <path> Or clearing it with: (lldb) settings clear target.process.python-os-plugin-path The process will now reload the OperatingSystem plug-in. This was implemented by: - adding the ability to set a notify callback for when an option value is changed - added the ability for the process plug-in to load the operating system plug-in on the fly - fixed bugs in the Process::GetStatus() so all threads are displayed if their thread IDs are larger than 32 bits - adding a callback in ProcessProperties to tell when the "python-os-plugin-path" is changed by the user - fixing a crasher in ProcessMachCore that happens when updating the thread list when the OS plugin is reloaded llvm-svn: 225831
2015-01-14 05:13:08 +08:00
m_collection_sp->SetValueChangedCallback(ePropertyPythonOSPluginPath, ProcessProperties::OptionValueChangedCallback, this);
}
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
}
Fix Clang-tidy modernize-use-override warnings in source/Target; other minor fixes. llvm-svn: 251134
2015-10-24 02:39:37 +08:00
ProcessProperties::~ProcessProperties() = default;
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
Fixed an issue where if the operating system python plug-in is changed at runtime, it wouldn't cause the process to reload the new operating system plug-in, now it does. This is currently controlled by a setting: (lldb) settings set target.process.python-os-plugin-path <path> Or clearing it with: (lldb) settings clear target.process.python-os-plugin-path The process will now reload the OperatingSystem plug-in. This was implemented by: - adding the ability to set a notify callback for when an option value is changed - added the ability for the process plug-in to load the operating system plug-in on the fly - fixed bugs in the Process::GetStatus() so all threads are displayed if their thread IDs are larger than 32 bits - adding a callback in ProcessProperties to tell when the "python-os-plugin-path" is changed by the user - fixing a crasher in ProcessMachCore that happens when updating the thread list when the OS plugin is reloaded llvm-svn: 225831
2015-01-14 05:13:08 +08:00
void
ProcessProperties::OptionValueChangedCallback (void *baton, OptionValue *option_value)
{
ProcessProperties *properties = (ProcessProperties *)baton;
if (properties->m_process)
properties->m_process->LoadOperatingSystemPlugin(true);
}
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
bool
ProcessProperties::GetDisableMemoryCache() const
{
const uint32_t idx = ePropertyDisableMemCache;
return m_collection_sp->GetPropertyAtIndexAsBoolean (NULL, idx, g_properties[idx].default_uint_value != 0);
}
Add a new target.process.memory-cache-line-size to change the size of lldb's internal memory cache chunks that are read from the remote system. For a remote connection that is especially slow, a user may need to reduce it; reading a 512 byte chunk of memory whenever a 4-byte region is requested may not be the right decision in these kinds of environments. <rdar://problem/18175117> llvm-svn: 217083
2014-09-04 06:30:54 +08:00
uint64_t
ProcessProperties::GetMemoryCacheLineSize() const
{
const uint32_t idx = ePropertyMemCacheLineSize;
return m_collection_sp->GetPropertyAtIndexAsUInt64 (NULL, idx, g_properties[idx].default_uint_value);
}
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
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);
}
Recommitting r180831 with trivial fix - remember to return errors if you compute. llvm-svn: 180898
2013-05-02 08:27:30 +08:00
bool
ProcessProperties::GetDetachKeepsStopped () const
{
const uint32_t idx = ePropertyDetachKeepsStopped;
return m_collection_sp->GetPropertyAtIndexAsBoolean(NULL, idx, g_properties[idx].default_uint_value != 0);
}
void
ProcessProperties::SetDetachKeepsStopped (bool stop)
{
const uint32_t idx = ePropertyDetachKeepsStopped;
m_collection_sp->SetPropertyAtIndexAsBoolean(NULL, idx, stop);
}
Second part of indicating when the user is stopped in optimized code. The first part was in r243508 -- the extent of the UI changes in that patchset was to add "[opt]" to the frame-format when a stack frame was built with optimized code. In this change, when a stack frame built with optimization is selected, a message will be printed to the async output channel -- opt1.c was compiled with optimization - stepping may behave oddly; variables may not be available. The warning will be only be printed once per source file in a debug session. These warnings may be disabled by settings set target.process.optimization-warnings false Internally, a new Process::PrintWarning() method has been added for warnings that we want to print only once to the user. It takes a type of warning (currently only eWarningsOptimization) and an object pointer (CompileUnit*) - the warning will only be printed once for a given object pointer value. This is a bit of a prototype of this change - I think we will be tweaking it more in the future. But I wanted to land this and see how it goes. Advanced users will find these warnings unnecessary noise and will quickly disable them - but anyone who maintains a debugger knows that debugging optimized code, without realizing it, is a constant source of confusion and frustation for more typical debugger users. I imagine there will be more of these "warn once per whatever" style warnings that we will want to add in the future and we'll need to come up with a better way for enabling/disabling them. But I'm not srue what form that warning settings should take and I didn't want to code up something that we regret later, so for now I just added another process setting for this one warning. <rdar://problem/19281172> llvm-svn: 244190
2015-08-06 11:27:10 +08:00
bool
ProcessProperties::GetWarningsOptimization () const
{
const uint32_t idx = ePropertyWarningOptimization;
return m_collection_sp->GetPropertyAtIndexAsBoolean (NULL, idx, g_properties[idx].default_uint_value != 0);
}
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);
}
}
ArchSpec: fix unintentional promotion of unspecified unknowns to specified unknowns * ArchSpec::MergeFrom() would erroneously promote an unspecified unknown to a specified unknown when both the ArchSpec and the merged in ArchSpec were both unspecified unknowns. This no longer happens, which fixes issues with global module cache lookup in some situations. * Added ArchSpec::DumpTriple(Stream&) that now properly prints unspecified unknowns as '*' and specified unknows as 'unknown'. This makes it trivial to tell the difference between the two. Converted printing code over ot using DumpTriple() rather than building from scratch. * Fixed up a couple places that were not guaranteeing that an unspecified unknown was recorded as such. llvm-svn: 250253
2015-10-14 07:41:19 +08:00
if (m_arch.IsValid())
{
s.Printf (" arch = ");
m_arch.DumpTriple(s);
s.EOL();
}
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
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
{
Fix a thinko in the process list formatting. Made Process::Attach list the matching processes if there is more than one match. <rdar://problem/18023352> llvm-svn: 215730
2014-08-16 01:05:27 +08:00
s.Printf ("PID PARENT USER TRIPLE %s\n", label);
s.PutCString ("====== ====== ========== ======================== ============================\n");
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
}
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
ArchSpec: fix unintentional promotion of unspecified unknowns to specified unknowns * ArchSpec::MergeFrom() would erroneously promote an unspecified unknown to a specified unknown when both the ArchSpec and the merged in ArchSpec were both unspecified unknowns. This no longer happens, which fixes issues with global module cache lookup in some situations. * Added ArchSpec::DumpTriple(Stream&) that now properly prints unspecified unknowns as '*' and specified unknows as 'unknown'. This makes it trivial to tell the difference between the two. Converted printing code over ot using DumpTriple() rather than building from scratch. * Fixed up a couple places that were not guaranteeing that an unspecified unknown was recorded as such. llvm-svn: 250253
2015-10-14 07:41:19 +08:00
StreamString arch_strm;
if (m_arch.IsValid())
m_arch.DumpTriple(arch_strm);
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);
ArchSpec: fix unintentional promotion of unspecified unknowns to specified unknowns * ArchSpec::MergeFrom() would erroneously promote an unspecified unknown to a specified unknown when both the ArchSpec and the merged in ArchSpec were both unspecified unknowns. This no longer happens, which fixes issues with global module cache lookup in some situations. * Added ArchSpec::DumpTriple(Stream&) that now properly prints unspecified unknowns as '*' and specified unknows as 'unknown'. This makes it trivial to tell the difference between the two. Converted printing code over ot using DumpTriple() rather than building from scratch. * Fixed up a couple places that were not guaranteeing that an unspecified unknown was recorded as such. llvm-svn: 250253
2015-10-14 07:41:19 +08:00
s.Printf ("%-24s ", arch_strm.GetString().c_str());
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
{
Fix a thinko in the process list formatting. Made Process::Attach list the matching processes if there is more than one match. <rdar://problem/18023352> llvm-svn: 215730
2014-08-16 01:05:27 +08:00
s.Printf ("%-10s %-24s ",
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),
ArchSpec: fix unintentional promotion of unspecified unknowns to specified unknowns * ArchSpec::MergeFrom() would erroneously promote an unspecified unknown to a specified unknown when both the ArchSpec and the merged in ArchSpec were both unspecified unknowns. This no longer happens, which fixes issues with global module cache lookup in some situations. * Added ArchSpec::DumpTriple(Stream&) that now properly prints unspecified unknowns as '*' and specified unknows as 'unknown'. This makes it trivial to tell the difference between the two. Converted printing code over ot using DumpTriple() rather than building from scratch. * Fixed up a couple places that were not guaranteeing that an unspecified unknown was recorded as such. llvm-svn: 250253
2015-10-14 07:41:19 +08:00
arch_strm.GetString().c_str());
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
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
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
Move FileSystem functions out of Host and into their own classes. More specifically, this change can be summarized as follows: 1) Makes an lldbHostPosix library which contains code common to all posix platforms. 2) Creates Host/FileSystem.h which defines a common FileSystem interface. 3) Implements FileSystem.h in Host/windows and Host/posix. 4) Creates Host/FileCache.h, implemented in Host/common, which defines a class useful for storing handles to open files needed by the debugger. Differential Revision: http://reviews.llvm.org/D4889 llvm-svn: 215775
2014-08-16 06:04:21 +08:00
{
FileAction action;
Refactor many file functions to use FileSpec over strings. Summary: This should solve the issue of sending denormalized paths over gdb-remote if we stick to GetPath(false) in GDBRemoteCommunicationClient, and let the server handle any denormalization. Reviewers: ovyalov, zturner, vharron, clayborg Reviewed By: clayborg Subscribers: tberghammer, emaste, lldb-commits Differential Revision: http://reviews.llvm.org/D9728 llvm-svn: 238604
2015-05-30 03:52:29 +08:00
if (action.Open(STDIN_FILENO, FileSpec{option_arg, false}, true, false))
Move FileSystem functions out of Host and into their own classes. More specifically, this change can be summarized as follows: 1) Makes an lldbHostPosix library which contains code common to all posix platforms. 2) Creates Host/FileSystem.h which defines a common FileSystem interface. 3) Implements FileSystem.h in Host/windows and Host/posix. 4) Creates Host/FileCache.h, implemented in Host/common, which defines a class useful for storing handles to open files needed by the debugger. Differential Revision: http://reviews.llvm.org/D4889 llvm-svn: 215775
2014-08-16 06:04:21 +08:00
launch_info.AppendFileAction (action);
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;
Move FileSystem functions out of Host and into their own classes. More specifically, this change can be summarized as follows: 1) Makes an lldbHostPosix library which contains code common to all posix platforms. 2) Creates Host/FileSystem.h which defines a common FileSystem interface. 3) Implements FileSystem.h in Host/windows and Host/posix. 4) Creates Host/FileCache.h, implemented in Host/common, which defines a class useful for storing handles to open files needed by the debugger. Differential Revision: http://reviews.llvm.org/D4889 llvm-svn: 215775
2014-08-16 06:04:21 +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
<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
Move FileSystem functions out of Host and into their own classes. More specifically, this change can be summarized as follows: 1) Makes an lldbHostPosix library which contains code common to all posix platforms. 2) Creates Host/FileSystem.h which defines a common FileSystem interface. 3) Implements FileSystem.h in Host/windows and Host/posix. 4) Creates Host/FileCache.h, implemented in Host/common, which defines a class useful for storing handles to open files needed by the debugger. Differential Revision: http://reviews.llvm.org/D4889 llvm-svn: 215775
2014-08-16 06:04:21 +08:00
{
FileAction action;
Refactor many file functions to use FileSpec over strings. Summary: This should solve the issue of sending denormalized paths over gdb-remote if we stick to GetPath(false) in GDBRemoteCommunicationClient, and let the server handle any denormalization. Reviewers: ovyalov, zturner, vharron, clayborg Reviewed By: clayborg Subscribers: tberghammer, emaste, lldb-commits Differential Revision: http://reviews.llvm.org/D9728 llvm-svn: 238604
2015-05-30 03:52:29 +08:00
if (action.Open(STDOUT_FILENO, FileSpec{option_arg, false}, false, true))
Move FileSystem functions out of Host and into their own classes. More specifically, this change can be summarized as follows: 1) Makes an lldbHostPosix library which contains code common to all posix platforms. 2) Creates Host/FileSystem.h which defines a common FileSystem interface. 3) Implements FileSystem.h in Host/windows and Host/posix. 4) Creates Host/FileCache.h, implemented in Host/common, which defines a class useful for storing handles to open files needed by the debugger. Differential Revision: http://reviews.llvm.org/D4889 llvm-svn: 215775
2014-08-16 06:04:21 +08:00
launch_info.AppendFileAction (action);
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;
Move FileSystem functions out of Host and into their own classes. More specifically, this change can be summarized as follows: 1) Makes an lldbHostPosix library which contains code common to all posix platforms. 2) Creates Host/FileSystem.h which defines a common FileSystem interface. 3) Implements FileSystem.h in Host/windows and Host/posix. 4) Creates Host/FileCache.h, implemented in Host/common, which defines a class useful for storing handles to open files needed by the debugger. Differential Revision: http://reviews.llvm.org/D4889 llvm-svn: 215775
2014-08-16 06:04:21 +08:00
}
<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
Move FileSystem functions out of Host and into their own classes. More specifically, this change can be summarized as follows: 1) Makes an lldbHostPosix library which contains code common to all posix platforms. 2) Creates Host/FileSystem.h which defines a common FileSystem interface. 3) Implements FileSystem.h in Host/windows and Host/posix. 4) Creates Host/FileCache.h, implemented in Host/common, which defines a class useful for storing handles to open files needed by the debugger. Differential Revision: http://reviews.llvm.org/D4889 llvm-svn: 215775
2014-08-16 06:04:21 +08:00
{
FileAction action;
Refactor many file functions to use FileSpec over strings. Summary: This should solve the issue of sending denormalized paths over gdb-remote if we stick to GetPath(false) in GDBRemoteCommunicationClient, and let the server handle any denormalization. Reviewers: ovyalov, zturner, vharron, clayborg Reviewed By: clayborg Subscribers: tberghammer, emaste, lldb-commits Differential Revision: http://reviews.llvm.org/D9728 llvm-svn: 238604
2015-05-30 03:52:29 +08:00
if (action.Open(STDERR_FILENO, FileSpec{option_arg, false}, false, true))
Move FileSystem functions out of Host and into their own classes. More specifically, this change can be summarized as follows: 1) Makes an lldbHostPosix library which contains code common to all posix platforms. 2) Creates Host/FileSystem.h which defines a common FileSystem interface. 3) Implements FileSystem.h in Host/windows and Host/posix. 4) Creates Host/FileCache.h, implemented in Host/common, which defines a class useful for storing handles to open files needed by the debugger. Differential Revision: http://reviews.llvm.org/D4889 llvm-svn: 215775
2014-08-16 06:04:21 +08:00
launch_info.AppendFileAction (action);
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;
Move FileSystem functions out of Host and into their own classes. More specifically, this change can be summarized as follows: 1) Makes an lldbHostPosix library which contains code common to all posix platforms. 2) Creates Host/FileSystem.h which defines a common FileSystem interface. 3) Implements FileSystem.h in Host/windows and Host/posix. 4) Creates Host/FileCache.h, implemented in Host/common, which defines a class useful for storing handles to open files needed by the debugger. Differential Revision: http://reviews.llvm.org/D4889 llvm-svn: 215775
2014-08-16 06:04:21 +08:00
}
<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
Move FileSystem functions out of Host and into their own classes. More specifically, this change can be summarized as follows: 1) Makes an lldbHostPosix library which contains code common to all posix platforms. 2) Creates Host/FileSystem.h which defines a common FileSystem interface. 3) Implements FileSystem.h in Host/windows and Host/posix. 4) Creates Host/FileCache.h, implemented in Host/common, which defines a class useful for storing handles to open files needed by the debugger. Differential Revision: http://reviews.llvm.org/D4889 llvm-svn: 215775
2014-08-16 06:04:21 +08:00
{
FileAction action;
Make uses of /dev/null portable across OSes. Most platforms have "/dev/null". Windows has "nul". Instead of hardcoding the string /dev/null at various places, make a constant that contains the correct value depending on the platform, and use that everywhere instead. llvm-svn: 250331
2015-10-15 05:37:36 +08:00
const FileSpec dev_null{FileSystem::DEV_NULL, false};
Refactor many file functions to use FileSpec over strings. Summary: This should solve the issue of sending denormalized paths over gdb-remote if we stick to GetPath(false) in GDBRemoteCommunicationClient, and let the server handle any denormalization. Reviewers: ovyalov, zturner, vharron, clayborg Reviewed By: clayborg Subscribers: tberghammer, emaste, lldb-commits Differential Revision: http://reviews.llvm.org/D9728 llvm-svn: 238604
2015-05-30 03:52:29 +08:00
if (action.Open(STDIN_FILENO, dev_null, true, false))
Move FileSystem functions out of Host and into their own classes. More specifically, this change can be summarized as follows: 1) Makes an lldbHostPosix library which contains code common to all posix platforms. 2) Creates Host/FileSystem.h which defines a common FileSystem interface. 3) Implements FileSystem.h in Host/windows and Host/posix. 4) Creates Host/FileCache.h, implemented in Host/common, which defines a class useful for storing handles to open files needed by the debugger. Differential Revision: http://reviews.llvm.org/D4889 llvm-svn: 215775
2014-08-16 06:04:21 +08:00
launch_info.AppendFileAction (action);
Refactor many file functions to use FileSpec over strings. Summary: This should solve the issue of sending denormalized paths over gdb-remote if we stick to GetPath(false) in GDBRemoteCommunicationClient, and let the server handle any denormalization. Reviewers: ovyalov, zturner, vharron, clayborg Reviewed By: clayborg Subscribers: tberghammer, emaste, lldb-commits Differential Revision: http://reviews.llvm.org/D9728 llvm-svn: 238604
2015-05-30 03:52:29 +08:00
if (action.Open(STDOUT_FILENO, dev_null, false, true))
Move FileSystem functions out of Host and into their own classes. More specifically, this change can be summarized as follows: 1) Makes an lldbHostPosix library which contains code common to all posix platforms. 2) Creates Host/FileSystem.h which defines a common FileSystem interface. 3) Implements FileSystem.h in Host/windows and Host/posix. 4) Creates Host/FileCache.h, implemented in Host/common, which defines a class useful for storing handles to open files needed by the debugger. Differential Revision: http://reviews.llvm.org/D4889 llvm-svn: 215775
2014-08-16 06:04:21 +08:00
launch_info.AppendFileAction (action);
Refactor many file functions to use FileSpec over strings. Summary: This should solve the issue of sending denormalized paths over gdb-remote if we stick to GetPath(false) in GDBRemoteCommunicationClient, and let the server handle any denormalization. Reviewers: ovyalov, zturner, vharron, clayborg Reviewed By: clayborg Subscribers: tberghammer, emaste, lldb-commits Differential Revision: http://reviews.llvm.org/D9728 llvm-svn: 238604
2015-05-30 03:52:29 +08:00
if (action.Open(STDERR_FILENO, dev_null, false, true))
Move FileSystem functions out of Host and into their own classes. More specifically, this change can be summarized as follows: 1) Makes an lldbHostPosix library which contains code common to all posix platforms. 2) Creates Host/FileSystem.h which defines a common FileSystem interface. 3) Implements FileSystem.h in Host/windows and Host/posix. 4) Creates Host/FileCache.h, implemented in Host/common, which defines a class useful for storing handles to open files needed by the debugger. Differential Revision: http://reviews.llvm.org/D4889 llvm-svn: 215775
2014-08-16 06:04:21 +08:00
launch_info.AppendFileAction (action);
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;
Move FileSystem functions out of Host and into their own classes. More specifically, this change can be summarized as follows: 1) Makes an lldbHostPosix library which contains code common to all posix platforms. 2) Creates Host/FileSystem.h which defines a common FileSystem interface. 3) Implements FileSystem.h in Host/windows and Host/posix. 4) Creates Host/FileCache.h, implemented in Host/common, which defines a class useful for storing handles to open files needed by the debugger. Differential Revision: http://reviews.llvm.org/D4889 llvm-svn: 215775
2014-08-16 06:04:21 +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 'w':
Refactor many file functions to use FileSpec over strings. Summary: This should solve the issue of sending denormalized paths over gdb-remote if we stick to GetPath(false) in GDBRemoteCommunicationClient, and let the server handle any denormalization. Reviewers: ovyalov, zturner, vharron, clayborg Reviewed By: clayborg Subscribers: tberghammer, emaste, lldb-commits Differential Revision: http://reviews.llvm.org/D9728 llvm-svn: 238604
2015-05-30 03:52:29 +08:00
launch_info.SetWorkingDirectory(FileSpec{option_arg, 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
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;
Adjust process launch --disable-aslr to take true/false value. This change modifies the 'process launch' --disable-aslr option to take a boolean argument. If the user directly specifies --disable-aslr {true,false}, that setting will control whether the process is launched with ASLR disabled accordingly. In the event that the setting is not explicitly made on the process launch command line, then the value is retrieved from the target.disable-aslr setting (i.e. settings show target.disable-aslr). llvm-svn: 215996
2014-08-20 01:40:43 +08:00
case 'A': // Disable ASLR.
{
bool success;
const bool disable_aslr_arg = Args::StringToBoolean (option_arg, true, &success);
if (success)
disable_aslr = disable_aslr_arg ? eLazyBoolYes : eLazyBoolNo;
else
error.SetErrorStringWithFormat ("Invalid boolean value for disable-aslr option: '%s'", option_arg ? option_arg : "<null>");
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;
Adjust process launch --disable-aslr to take true/false value. This change modifies the 'process launch' --disable-aslr option to take a boolean argument. If the user directly specifies --disable-aslr {true,false}, that setting will control whether the process is launched with ASLR disabled accordingly. In the event that the setting is not explicitly made on the process launch command line, then the value is retrieved from the target.disable-aslr setting (i.e. settings show target.disable-aslr). llvm-svn: 215996
2014-08-20 01:40:43 +08:00
}
Rename the "glob arguments" feature to "shell expand arguments" This should not bring any feature change, except changing names of things here and there llvm-svn: 230077
2015-02-21 06:20:30 +08:00
case 'X': // shell expand args.
Add a "launch with globber" mode that lets you launch a process after having globbed the command line arguments via argdumper instead of routing via /bin/sh llvm-svn: 228658
2015-02-10 11:06:24 +08:00
{
bool success;
Rename the "glob arguments" feature to "shell expand arguments" This should not bring any feature change, except changing names of things here and there llvm-svn: 230077
2015-02-21 06:20:30 +08:00
const bool expand_args = Args::StringToBoolean (option_arg, true, &success);
Add a "launch with globber" mode that lets you launch a process after having globbed the command line arguments via argdumper instead of routing via /bin/sh llvm-svn: 228658
2015-02-10 11:06:24 +08:00
if (success)
Rename the "glob arguments" feature to "shell expand arguments" This should not bring any feature change, except changing names of things here and there llvm-svn: 230077
2015-02-21 06:20:30 +08:00
launch_info.SetShellExpandArguments(expand_args);
Add a "launch with globber" mode that lets you launch a process after having globbed the command line arguments via argdumper instead of routing via /bin/sh llvm-svn: 228658
2015-02-10 11:06:24 +08:00
else
Rename the "glob arguments" feature to "shell expand arguments" This should not bring any feature change, except changing names of things here and there llvm-svn: 230077
2015-02-21 06:20:30 +08:00
error.SetErrorStringWithFormat ("Invalid boolean value for shell-expand-args option: '%s'", option_arg ? option_arg : "<null>");
Add a "launch with globber" mode that lets you launch a process after having globbed the command line arguments via argdumper instead of routing via /bin/sh llvm-svn: 228658
2015-02-10 11:06:24 +08:00
break;
}
Adjust process launch --disable-aslr to take true/false value. This change modifies the 'process launch' --disable-aslr option to take a boolean argument. If the user directly specifies --disable-aslr {true,false}, that setting will control whether the process is launched with ASLR disabled accordingly. In the event that the setting is not explicitly made on the process launch command line, then the value is retrieved from the target.disable-aslr setting (i.e. settings show target.disable-aslr). llvm-svn: 215996
2014-08-20 01:40:43 +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])
Remove LLDB_DEFAULT_SHELL #define, and determine this at runtime. Differential Revision: http://reviews.llvm.org/D5805 Reviewed by: Greg Clayton llvm-svn: 220217
2014-10-21 01:46:43 +08:00
launch_info.SetShell (FileSpec(option_arg, 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
else
Remove LLDB_DEFAULT_SHELL #define, and determine this at runtime. Differential Revision: http://reviews.llvm.org/D5805 Reviewed by: Greg Clayton llvm-svn: 220217
2014-10-21 01:46:43 +08:00
launch_info.SetShell (HostInfo::GetDefaultShell());
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[] =
{
Revert "Fix broken tests due to new error output." This reverts commit ec7c94f8e6860968d384b578e5564a9c55c80b4a and re-enables OptionValidators. llvm-svn: 212627
2014-07-10 00:31:49 +08:00
{ LLDB_OPT_SET_ALL, false, "stop-at-entry", 's', OptionParser::eNoArgument, NULL, NULL, 0, eArgTypeNone, "Stop at the entry point of the program when launching a process."},
Adjust process launch --disable-aslr to take true/false value. This change modifies the 'process launch' --disable-aslr option to take a boolean argument. If the user directly specifies --disable-aslr {true,false}, that setting will control whether the process is launched with ASLR disabled accordingly. In the event that the setting is not explicitly made on the process launch command line, then the value is retrieved from the target.disable-aslr setting (i.e. settings show target.disable-aslr). llvm-svn: 215996
2014-08-20 01:40:43 +08:00
{ LLDB_OPT_SET_ALL, false, "disable-aslr", 'A', OptionParser::eRequiredArgument, NULL, NULL, 0, eArgTypeBoolean, "Set whether to disable address space layout randomization when launching a process."},
Revert "Fix broken tests due to new error output." This reverts commit ec7c94f8e6860968d384b578e5564a9c55c80b4a and re-enables OptionValidators. llvm-svn: 212627
2014-07-10 00:31:49 +08:00
{ LLDB_OPT_SET_ALL, false, "plugin", 'p', OptionParser::eRequiredArgument, NULL, NULL, 0, eArgTypePlugin, "Name of the process plugin you want to use."},
{ LLDB_OPT_SET_ALL, false, "working-dir", 'w', OptionParser::eRequiredArgument, NULL, NULL, 0, eArgTypeDirectoryName, "Set the current working directory to <path> when running the inferior."},
{ LLDB_OPT_SET_ALL, false, "arch", 'a', OptionParser::eRequiredArgument, NULL, NULL, 0, eArgTypeArchitecture, "Set the architecture for the process to launch when ambiguous."},
{ LLDB_OPT_SET_ALL, false, "environment", 'v', OptionParser::eRequiredArgument, NULL, NULL, 0, eArgTypeNone, "Specify an environment variable name/value string (--environment NAME=VALUE). Can be specified multiple times for subsequent environment entries."},
Add a "launch with globber" mode that lets you launch a process after having globbed the command line arguments via argdumper instead of routing via /bin/sh llvm-svn: 228658
2015-02-10 11:06:24 +08:00
{ LLDB_OPT_SET_1|LLDB_OPT_SET_2|LLDB_OPT_SET_3, false, "shell", 'c', OptionParser::eOptionalArgument, NULL, 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
Revert "Fix broken tests due to new error output." This reverts commit ec7c94f8e6860968d384b578e5564a9c55c80b4a and re-enables OptionValidators. llvm-svn: 212627
2014-07-10 00:31:49 +08:00
{ LLDB_OPT_SET_1 , false, "stdin", 'i', OptionParser::eRequiredArgument, NULL, NULL, 0, eArgTypeFilename, "Redirect stdin for the process to <filename>."},
{ LLDB_OPT_SET_1 , false, "stdout", 'o', OptionParser::eRequiredArgument, NULL, NULL, 0, eArgTypeFilename, "Redirect stdout for the process to <filename>."},
{ LLDB_OPT_SET_1 , false, "stderr", 'e', OptionParser::eRequiredArgument, NULL, 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
Revert "Fix broken tests due to new error output." This reverts commit ec7c94f8e6860968d384b578e5564a9c55c80b4a and re-enables OptionValidators. llvm-svn: 212627
2014-07-10 00:31:49 +08:00
{ LLDB_OPT_SET_2 , false, "tty", 't', OptionParser::eNoArgument, NULL, NULL, 0, eArgTypeNone, "Start the process in a terminal (not supported on all platforms)."},
Moved the execution context that was in the Debugger into the CommandInterpreter where it was always being used. Make sure that Modules can track their object file offsets correctly to allow opening of sub object files (like the "__commpage" on darwin). Modified the Platforms to be able to launch processes. The first part of this move is the platform soon will become the entity that launches your program and when it does, it uses a new ProcessLaunchInfo class which encapsulates all process launching settings. This simplifies the internal APIs needed for launching. I want to slowly phase out process launching from the process classes, so for now we can still launch just as we used to, but eventually the platform is the object that should do the launching. Modified the Host::LaunchProcess in the MacOSX Host.mm to correctly be able to launch processes with all of the new eLaunchFlag settings. Modified any code that was manually launching processes to use the Host::LaunchProcess functions. Fixed an issue where lldb_private::Args had implicitly defined copy constructors that could do the wrong thing. This has now been fixed by adding an appropriate copy constructor and assignment operator. Make sure we don't add empty ModuleSP entries to a module list. Fixed the commpage module creation on MacOSX, but we still need to train the MacOSX dynamic loader to not get rid of it when it doesn't have an entry in the all image infos. Abstracted many more calls from in ProcessGDBRemote down into the GDBRemoteCommunicationClient subclass to make the classes cleaner and more efficient. Fixed the default iOS ARM register context to be correct and also added support for targets that don't support the qThreadStopInfo packet by selecting the current thread (only if needed) and then sending a stop reply packet. Debugserver can now start up with a --unix-socket (-u for short) and can then bind to port zero and send the port it bound to to a listening process on the other end. This allows the GDB remote platform to spawn new GDB server instances (debugserver) to allow platform debugging. llvm-svn: 129351
2011-04-12 13:54:46 +08:00
Revert "Fix broken tests due to new error output." This reverts commit ec7c94f8e6860968d384b578e5564a9c55c80b4a and re-enables OptionValidators. llvm-svn: 212627
2014-07-10 00:31:49 +08:00
{ LLDB_OPT_SET_3 , false, "no-stdio", 'n', OptionParser::eNoArgument, NULL, NULL, 0, eArgTypeNone, "Do not set up for terminal I/O to go to running process."},
Rename the "glob arguments" feature to "shell expand arguments" This should not bring any feature change, except changing names of things here and there llvm-svn: 230077
2015-02-21 06:20:30 +08:00
{ LLDB_OPT_SET_4, false, "shell-expand-args", 'X', OptionParser::eRequiredArgument, NULL, NULL, 0, eArgTypeBoolean, "Set whether to shell expand arguments to the process when launching."},
Revert "Fix broken tests due to new error output." This reverts commit ec7c94f8e6860968d384b578e5564a9c55c80b4a and re-enables OptionValidators. llvm-svn: 212627
2014-07-10 00:31:49 +08:00
{ 0 , false, NULL, 0, 0, NULL, NULL, 0, eArgTypeNone, NULL }
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
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
Have the Process hold a weak_ptr to the Target. llvm-svn: 246578
2015-09-02 04:02:29 +08:00
Process::FindPlugin (lldb::TargetSP target_sp, 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)
{
<rdar://problem/13854277> <rdar://problem/13594769> Main changes in this patch include: - cleanup plug-in interface and use ConstStrings for plug-in names - Modfiied the BSD Archive plug-in to be able to pick out the correct .o file when .a files contain multiple .o files with the same name by using the timestamp - Modified SymbolFileDWARFDebugMap to properly verify the timestamp on .o files it loads to ensure we don't load updated .o files and cause problems when debugging The plug-in interface changes: Modified the lldb_private::PluginInterface class that all plug-ins inherit from: Changed: virtual const char * GetPluginName() = 0; To: virtual ConstString GetPluginName() = 0; Removed: virtual const char * GetShortPluginName() = 0; - Fixed up all plug-in to adhere to the new interface and to return lldb_private::ConstString values for the plug-in names. - Fixed all plug-ins to return simple names with no prefixes. Some plug-ins had prefixes and most ones didn't, so now they all don't have prefixed names, just simple names like "linux", "gdb-remote", etc. llvm-svn: 181631
2013-05-11 05:47:16 +08:00
ConstString const_plugin_name(plugin_name);
create_callback = PluginManager::GetProcessCreateCallbackForPluginName (const_plugin_name);
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
if (create_callback)
{
Have the Process hold a weak_ptr to the Target. llvm-svn: 246578
2015-09-02 04:02:29 +08:00
process_sp = create_callback(target_sp, listener, crash_file_path);
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
if (process_sp)
{
Have the Process hold a weak_ptr to the Target. llvm-svn: 246578
2015-09-02 04:02:29 +08:00
if (process_sp->CanDebug(target_sp, true))
<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
{
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
{
Have the Process hold a weak_ptr to the Target. llvm-svn: 246578
2015-09-02 04:02:29 +08:00
process_sp = create_callback(target_sp, listener, crash_file_path);
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
if (process_sp)
{
Have the Process hold a weak_ptr to the Target. llvm-svn: 246578
2015-09-02 04:02:29 +08:00
if (process_sp->CanDebug(target_sp, false))
<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
{
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
Have the Process hold a weak_ptr to the Target. llvm-svn: 246578
2015-09-02 04:02:29 +08:00
Process::Process(lldb::TargetSP target_sp, Listener &listener) :
Process(target_sp, listener, UnixSignals::Create(HostInfo::GetArchitecture()))
Consolidate UnixSignals setting/getting in Process. See http://reviews.llvm.org/D5108 for details. This change does the following: * eliminates the Process::GetUnixSignals() virtual method and replaces with a fixed getter. * replaces the Process UnixSignals storage with a shared pointer. * adds a Process constructor variant that can be passed the UnixSignalsSP. When the constructor without the UnixSignalsSP is specified, the Host's default UnixSignals is used. * adds a host-specific version of GetUnixSignals() that is used when we need the host's appropriate UnixSignals variant. * replaces GetUnixSignals() overrides in PlatformElfCore, ProcessGDBRemote, ProcessFreeBSD and ProcessLinux with code that appropriately sets the Process::UnixSignals for the process. This change also enables some future patches that will enable llgs to be used for local Linux debugging. llvm-svn: 216748
2014-08-30 01:35:57 +08:00
{
// This constructor just delegates to the full Process constructor,
// defaulting to using the Host's UnixSignals.
}
Have the Process hold a weak_ptr to the Target. llvm-svn: 246578
2015-09-02 04:02:29 +08:00
Process::Process(lldb::TargetSP target_sp, Listener &listener, const UnixSignalsSP &unix_signals_sp) :
Fixed an issue where if the operating system python plug-in is changed at runtime, it wouldn't cause the process to reload the new operating system plug-in, now it does. This is currently controlled by a setting: (lldb) settings set target.process.python-os-plugin-path <path> Or clearing it with: (lldb) settings clear target.process.python-os-plugin-path The process will now reload the OperatingSystem plug-in. This was implemented by: - adding the ability to set a notify callback for when an option value is changed - added the ability for the process plug-in to load the operating system plug-in on the fly - fixed bugs in the Process::GetStatus() so all threads are displayed if their thread IDs are larger than 32 bits - adding a callback in ProcessProperties to tell when the "python-os-plugin-path" is changed by the user - fixing a crasher in ProcessMachCore that happens when updating the thread list when the OS plugin is reloaded llvm-svn: 225831
2015-01-14 05:13:08 +08:00
ProcessProperties (this),
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),
Have the Process hold a weak_ptr to the Target. llvm-svn: 246578
2015-09-02 04:02:29 +08:00
Broadcaster (&(target_sp->GetDebugger()), Process::GetStaticBroadcasterClass().AsCString()),
m_target_sp (target_sp),
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
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(),
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 (),
use std::atomic<> to protect variables being accessed by multiple threads There are several places where multiple threads are accessing the same variables simultaneously without any kind of protection. I propose using std::atomic<> to make it safer. I did a special build of lldb, using the google tool 'thread sanitizer' which identified many cases of multiple threads accessing the same memory. std::atomic is low overhead and does not use any locks for simple types such as int/bool. See http://reviews.llvm.org/D5302 for more details. Change by Shawn Best. llvm-svn: 217818
2014-09-16 04:07:33 +08:00
m_exit_status_mutex(),
Reinstating r181091 and r181106 with fix for Linux regressions. llvm-svn: 181340
2013-05-08 02:35:34 +08:00
m_thread_mutex (Mutex::eMutexTypeRecursive),
m_thread_list_real (this),
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
m_thread_list (this),
The Threads created when requesting extended backtraces need to be owned by something; add a new ExtendedThreadList to Process where they can be retained for the duration of a public stop. <rdar://problem/15314068> llvm-svn: 194367
2013-11-11 13:20:44 +08:00
m_extended_thread_list (this),
Flush the Process' cache of extended threads every time the natural stop id is updated. <rdar://problem/15496603> llvm-svn: 195177
2013-11-20 08:31:38 +08:00
m_extended_thread_stop_id (0),
Add new Queue, QueueItem, Queuelist, SBQueue, SBQueueItem classes to represent libdispatch aka Grand Central Dispatch (GCD) queues. Still fleshing out the documentation and testing of these but the overall API is settling down so it's a good time to check it in. <rdar://problem/15600370> llvm-svn: 197190
2013-12-13 08:29:16 +08:00
m_queue_list (this),
m_queue_list_stop_id (0),
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
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 (),
Consolidate UnixSignals setting/getting in Process. See http://reviews.llvm.org/D5108 for details. This change does the following: * eliminates the Process::GetUnixSignals() virtual method and replaces with a fixed getter. * replaces the Process UnixSignals storage with a shared pointer. * adds a Process constructor variant that can be passed the UnixSignalsSP. When the constructor without the UnixSignalsSP is specified, the Host's default UnixSignals is used. * adds a host-specific version of GetUnixSignals() that is used when we need the host's appropriate UnixSignals variant. * replaces GetUnixSignals() overrides in PlatformElfCore, ProcessGDBRemote, ProcessFreeBSD and ProcessLinux with code that appropriately sets the Process::UnixSignals for the process. This change also enables some future patches that will enable llgs to be used for local Linux debugging. llvm-svn: 216748
2014-08-30 01:35:57 +08:00
m_unix_signals_sp (unix_signals_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
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),
Fix 'process launch -i' for remote processes We want to forward stdin when stdio is not disabled and when we're not redirecting stdin from a file. renamed m_stdio_disable to m_stdin_forward and inverted value because that's what we want to remember. There was previously a bug that if you redirected stdin from a file, stdout and stderr would also be redirected to /dev/null Adds support for remote target to TestProcessIO.py Fixes ProcessIOTestCase.test_stdin_redirection_with_dwarf for remote Linux targets llvm-svn: 228744
2015-02-11 05:09:04 +08:00
m_stdin_forward (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
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 (),
Improve LLDB prompt handling Summary: There is an issue in lldb where the command prompt can appear at the wrong time. The partial fix we have in for this is not working all the time and is introducing unnecessary delays. This change does: - Change Process:SyncIOHandler to use integer start id's for synchronization to avoid it being confused by quick start-stop cycles. I picked this up from a suggested patch by Greg to lldb-dev. - coordinates printing of asynchronous text with the iohandlers. This is also based on a (different) Greg's patch, but I have added stronger synchronization to it to avoid races. Together, these changes solve the prompt problem for me on linux (both with and without libedit). I think they should behave similarly on Mac and FreeBSD and I think they will not make matters worse for windows. Test Plan: Prompt comes out alright. All tests still pass on linux. Reviewers: clayborg, emaste, zturner Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D9823 llvm-svn: 238313
2015-05-27 20:40:32 +08:00
m_iohandler_sync (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
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(),
Re-enable m_private_run_lock changes from 179329, but only for Apple hosted builds so it doesn't break the buildbots. We will try and work the issues out in the Apple build before enabling this feature for everyone. llvm-svn: 179772
2013-04-19 00:57:27 +08:00
m_public_run_lock (),
m_private_run_lock (),
Handle thumb IT instructions correctly all the time. The issue with Thumb IT (if/then) instructions is the IT instruction preceeds up to four instructions that are made conditional. If a breakpoint is placed on one of the conditional instructions, the instruction either needs to match the thumb opcode size (2 or 4 bytes) or a BKPT instruction needs to be used as these are always unconditional (even in a IT instruction). If BKPT instructions are used, then we might end up stopping on an instruction that won't get executed. So if we do stop at a BKPT instruction, we need to continue if the condition is not true. When using the BKPT isntructions are easy in that you don't need to detect the size of the breakpoint that needs to be used when setting a breakpoint even in a thumb IT instruction. The bad part is you will now always stop at the opcode location and let LLDB determine if it should auto-continue. If the BKPT instruction is used, the BKPT that is used for ARM code should be something that also triggers the BKPT instruction in Thumb in case you set a breakpoint in the middle of code and the code is actually Thumb code. A value of 0xE120BE70 will work since the lower 16 bits being 0xBE70 happens to be a Thumb BKPT instruction. The alternative is to use trap or illegal instructions that the kernel will translate into breakpoint hits. On Mac this was 0xE7FFDEFE for ARM and 0xDEFE for Thumb. The darwin kernel currently doesn't recognize any 32 bit Thumb instruction as a instruction that will get turned into a breakpoint exception (EXC_BREAKPOINT), so we had to use the BKPT instruction on Mac. The linux kernel recognizes a 16 and a 32 bit instruction as valid thumb breakpoint opcodes. The benefit of using 16 or 32 bit instructions is you don't stop on opcodes in a IT block when the condition doesn't match. To further complicate things, single stepping on ARM is often implemented by modifying the BCR/BVR registers and setting the processor to stop when the PC is not equal to the current value. This means single stepping is another way the ARM target can stop on instructions that won't get executed. This patch does the following: 1 - Fix the internal debugserver for Apple to use the BKPT instruction for ARM and Thumb 2 - Fix LLDB to catch when we stop in the middle of a Thumb IT instruction and continue if we stop at an instruction that won't execute 3 - Fixes this in a way that will work for any target on any platform as long as it is ARM/Thumb 4 - Adds a patch for ignoring conditions that don't match when in ARM mode (see below) This patch also provides the code that implements the same thing for ARM instructions, though it is disabled for now. The ARM patch will check the condition of the instruction in ARM mode and continue if the condition isn't true (and therefore the instruction would not be executed). Again, this is not enable, but the code for it has been added. <rdar://problem/19145455> llvm-svn: 223851
2014-12-10 07:31:02 +08:00
m_stop_info_override_callback (NULL),
Fix a crasher that could happen when you run LLDB and evaluate an expression where the objective C runtime registers a helper function, and also have an Objective C or C++ exception breakpoint. When shutting down the process in Process::Finalize() we clear a STL collection class and that causes objects to be destroyed that could re-enter Process and cause it to try to iterate over that same collection class that is being destroyed. Guard against this by setting a new "m_finalizing" flag that lets us know we are in the process of finalizing. <rdar://problem/20369152> llvm-svn: 233935
2015-04-03 02:44:58 +08:00
m_finalizing (false),
m_finalize_called (false),
<rdar://problem/13700260> Avoid a deadlock when using the OperatingSystemPython code and typing "process interrupt". There was a possible lock inversion between the target API lock and the process' thread list lock due to code trying to discard the thread list. This was fixed by adding a boolean to Process::Halt() that indicates if the thread plans should be discarded and doing it in the private state thread when we process the stopped state. llvm-svn: 181651
2013-05-11 07:48:10 +08:00
m_clear_thread_plans_on_stop (false),
Fix a crasher that could happen when you run LLDB and evaluate an expression where the objective C runtime registers a helper function, and also have an Objective C or C++ exception breakpoint. When shutting down the process in Process::Finalize() we clear a STL collection class and that causes objects to be destroyed that could re-enter Process and cause it to try to iterate over that same collection class that is being destroyed. Guard against this by setting a new "m_finalizing" flag that lets us know we are in the process of finalizing. <rdar://problem/20369152> llvm-svn: 233935
2015-04-03 02:44:58 +08:00
m_force_next_event_delivery (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),
Expression evaluation, a new ThreadPlanCallFunctionUsingABI for executing a function call on target via register manipulation For Hexagon we want to be able to call functions during debugging, however currently lldb only supports this when there is JIT support. Although emulation using IR interpretation is an alternative, it is currently limited in that it can't make function calls. In this patch we have extended the IR interpreter so that it can execute a function call on the target using register manipulation. To do this we need to handle the Call IR instruction, passing arguments to a new thread plan and collecting any return values to pass back into the IR interpreter. The new thread plan is needed to call an alternative ABI interface of "ABI::PerpareTrivialCall()", allowing more detailed information about arguments and return values. Reviewers: jingham, spyffe Subscribers: emaste, lldb-commits, ted, ADodds, deepak2427 Differential Revision: http://reviews.llvm.org/D9404 llvm-svn: 242137
2015-07-14 18:56:58 +08:00
m_can_interpret_function_calls(false),
Second part of indicating when the user is stopped in optimized code. The first part was in r243508 -- the extent of the UI changes in that patchset was to add "[opt]" to the frame-format when a stack frame was built with optimized code. In this change, when a stack frame built with optimization is selected, a message will be printed to the async output channel -- opt1.c was compiled with optimization - stepping may behave oddly; variables may not be available. The warning will be only be printed once per source file in a debug session. These warnings may be disabled by settings set target.process.optimization-warnings false Internally, a new Process::PrintWarning() method has been added for warnings that we want to print only once to the user. It takes a type of warning (currently only eWarningsOptimization) and an object pointer (CompileUnit*) - the warning will only be printed once for a given object pointer value. This is a bit of a prototype of this change - I think we will be tweaking it more in the future. But I wanted to land this and see how it goes. Advanced users will find these warnings unnecessary noise and will quickly disable them - but anyone who maintains a debugger knows that debugging optimized code, without realizing it, is a constant source of confusion and frustation for more typical debugger users. I imagine there will be more of these "warn once per whatever" style warnings that we will want to add in the future and we'll need to come up with a better way for enabling/disabling them. But I'm not srue what form that warning settings should take and I didn't want to code up something that we regret later, so for now I just added another process setting for this one warning. <rdar://problem/19281172> llvm-svn: 244190
2015-08-06 11:27:10 +08:00
m_warnings_issued (),
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_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)
sweep up -Wformat warnings from gcc This is a purely mechanical change explicitly casting any parameters for printf style conversion. This cleans up the warnings emitted by gcc 4.8 on Linux. llvm-svn: 205607
2014-04-04 12:06:10 +08:00
log->Printf ("%p Process::Process()", static_cast<void*>(this));
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
Consolidate UnixSignals setting/getting in Process. See http://reviews.llvm.org/D5108 for details. This change does the following: * eliminates the Process::GetUnixSignals() virtual method and replaces with a fixed getter. * replaces the Process UnixSignals storage with a shared pointer. * adds a Process constructor variant that can be passed the UnixSignalsSP. When the constructor without the UnixSignalsSP is specified, the Host's default UnixSignals is used. * adds a host-specific version of GetUnixSignals() that is used when we need the host's appropriate UnixSignals variant. * replaces GetUnixSignals() overrides in PlatformElfCore, ProcessGDBRemote, ProcessFreeBSD and ProcessLinux with code that appropriately sets the Process::UnixSignals for the process. This change also enables some future patches that will enable llgs to be used for local Linux debugging. llvm-svn: 216748
2014-08-30 01:35:57 +08:00
if (!m_unix_signals_sp)
Refactor Unix signals. Summary: - Consolidate Unix signals selection in UnixSignals. - Make Unix signals available from platform. - Add jSignalsInfo packet to retrieve Unix signals from remote platform. - Get a copy of the platform signal for each remote process. - Update SB API for signals. - Update signal utility in test suite. Reviewers: ovyalov, clayborg Subscribers: chaoren, jingham, labath, emaste, tberghammer, lldb-commits Differential Revision: http://reviews.llvm.org/D11094 llvm-svn: 242101
2015-07-14 09:09:28 +08:00
m_unix_signals_sp = std::make_shared<UnixSignals>();
Consolidate UnixSignals setting/getting in Process. See http://reviews.llvm.org/D5108 for details. This change does the following: * eliminates the Process::GetUnixSignals() virtual method and replaces with a fixed getter. * replaces the Process UnixSignals storage with a shared pointer. * adds a Process constructor variant that can be passed the UnixSignalsSP. When the constructor without the UnixSignalsSP is specified, the Host's default UnixSignals is used. * adds a host-specific version of GetUnixSignals() that is used when we need the host's appropriate UnixSignals variant. * replaces GetUnixSignals() overrides in PlatformElfCore, ProcessGDBRemote, ProcessFreeBSD and ProcessLinux with code that appropriately sets the Process::UnixSignals for the process. This change also enables some future patches that will enable llgs to be used for local Linux debugging. llvm-svn: 216748
2014-08-30 01:35:57 +08:00
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");
Refactor Unix signals. Summary: - Consolidate Unix signals selection in UnixSignals. - Make Unix signals available from platform. - Add jSignalsInfo packet to retrieve Unix signals from remote platform. - Get a copy of the platform signal for each remote process. - Update SB API for signals. - Update signal utility in test suite. Reviewers: ovyalov, clayborg Subscribers: chaoren, jingham, labath, emaste, tberghammer, lldb-commits Differential Revision: http://reviews.llvm.org/D11094 llvm-svn: 242101
2015-07-14 09:09:28 +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);
Consolidate UnixSignals setting/getting in Process. See http://reviews.llvm.org/D5108 for details. This change does the following: * eliminates the Process::GetUnixSignals() virtual method and replaces with a fixed getter. * replaces the Process UnixSignals storage with a shared pointer. * adds a Process constructor variant that can be passed the UnixSignalsSP. When the constructor without the UnixSignalsSP is specified, the Host's default UnixSignals is used. * adds a host-specific version of GetUnixSignals() that is used when we need the host's appropriate UnixSignals variant. * replaces GetUnixSignals() overrides in PlatformElfCore, ProcessGDBRemote, ProcessFreeBSD and ProcessLinux with code that appropriately sets the Process::UnixSignals for the process. This change also enables some future patches that will enable llgs to be used for local Linux debugging. llvm-svn: 216748
2014-08-30 01:35:57 +08:00
// We need something valid here, even if just the default UnixSignalsSP.
assert (m_unix_signals_sp && "null m_unix_signals_sp after initialization");
Increase default memory cache line size for android Summary: ADB packets have a maximum size of 4k. This means the size of memory reads does not affect speed too much (as long as it fits in one packet). Therefore, I am increasing the default memory read size for android to 2k. This value is used only if the user has not modified the default memory-cache-line-size setting. Reviewers: clayborg, tberghammer Subscribers: tberghammer, danalbert, srhines, lldb-commits Differential Revision: http://reviews.llvm.org/D13812 llvm-svn: 250814
2015-10-20 18:33:17 +08:00
// Allow the platform to override the default cache line size
OptionValueSP value_sp =
m_collection_sp->GetPropertyAtIndex(nullptr, true, ePropertyMemCacheLineSize)->GetValue();
uint32_t platform_cache_line_size = target_sp->GetPlatform()->GetDefaultMemoryCacheLineSize();
if (! value_sp->OptionWasSet() && platform_cache_line_size != 0)
value_sp->SetUInt64Value(platform_cache_line_size);
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
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)
sweep up -Wformat warnings from gcc This is a purely mechanical change explicitly casting any parameters for printf style conversion. This cleans up the warnings emitted by gcc 4.8 on Linux. llvm-svn: 205607
2014-04-04 12:06:10 +08:00
log->Printf ("%p Process::~Process()", static_cast<void*>(this));
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
StopPrivateStateThread();
Create a HostThread abstraction. This patch moves creates a thread abstraction that represents a thread running inside the LLDB process. This is a replacement for otherwise using lldb::thread_t, and provides a platform agnostic interface to managing these threads. Differential Revision: http://reviews.llvm.org/D5198 Reviewed by: Jim Ingham llvm-svn: 217460
2014-09-10 04:54:56 +08:00
// ThreadList::Clear() will try to acquire this process's mutex, so
// explicitly clear the thread list here to ensure that the mutex
// is not destroyed before the thread list.
m_thread_list.Clear();
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +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 ProcessPropertiesSP &
Process::GetGlobalProperties()
{
static ProcessPropertiesSP g_settings_sp;
if (!g_settings_sp)
Fixed an issue where if the operating system python plug-in is changed at runtime, it wouldn't cause the process to reload the new operating system plug-in, now it does. This is currently controlled by a setting: (lldb) settings set target.process.python-os-plugin-path <path> Or clearing it with: (lldb) settings clear target.process.python-os-plugin-path The process will now reload the OperatingSystem plug-in. This was implemented by: - adding the ability to set a notify callback for when an option value is changed - added the ability for the process plug-in to load the operating system plug-in on the fly - fixed bugs in the Process::GetStatus() so all threads are displayed if their thread IDs are larger than 32 bits - adding a callback in ProcessProperties to tell when the "python-os-plugin-path" is changed by the user - fixing a crasher in ProcessMachCore that happens when updating the thread list when the OS plugin is reloaded llvm-svn: 225831
2015-01-14 05:13:08 +08:00
g_settings_sp.reset (new ProcessProperties (NULL));
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
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()
{
Fix a crasher that could happen when you run LLDB and evaluate an expression where the objective C runtime registers a helper function, and also have an Objective C or C++ exception breakpoint. When shutting down the process in Process::Finalize() we clear a STL collection class and that causes objects to be destroyed that could re-enter Process and cause it to try to iterate over that same collection class that is being destroyed. Guard against this by setting a new "m_finalizing" flag that lets us know we are in the process of finalizing. <rdar://problem/20369152> llvm-svn: 233935
2015-04-03 02:44:58 +08:00
m_finalizing = true;
Fix Process::Finalize to do Process::Destroy if needed after r233255 llvm-svn: 233258
2015-03-26 15:40:40 +08:00
// Destroy this process if needed
switch (GetPrivateState())
{
case eStateConnected:
case eStateAttaching:
case eStateLaunching:
case eStateStopped:
case eStateRunning:
case eStateStepping:
case eStateCrashed:
case eStateSuspended:
Add a "force_kill" arg to Process::Destroy(). This is needed after the changes in r233255/r233258. Normally if lldb attaches to a running process, when we call Process::Destroy, we want to detach from the process. If lldb launched the process itself, ::Destroy should kill it. However, if we attach to a process and the driver calls SBProcess::Kill() (which calls Destroy), we need to kill it even if we didn't launch it originally. The force_kill param allows for the SBProcess::Kill method to force the behavior of Destroy. <rdar://problem/20424439> llvm-svn: 235158
2015-04-17 13:01:58 +08:00
Destroy(false);
Fix Process::Finalize to do Process::Destroy if needed after r233255 llvm-svn: 233258
2015-03-26 15:40:40 +08:00
break;
case eStateInvalid:
case eStateUnloaded:
case eStateDetached:
case eStateExited:
break;
}
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
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();
Add a new system runtime plugin type - just the top level class, not any actual plugin implementation yet. <rdar://problem/15314068> llvm-svn: 194044
2013-11-05 11:57:19 +08:00
m_system_runtime_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();
Add support for JIT debugging on Linux using the GDB JIT interface. Patch written with Keno Fischer. llvm-svn: 202956
2014-03-05 18:12:43 +08:00
m_jit_loaders_ap.reset();
Reinstating r181091 and r181106 with fix for Linux regressions. llvm-svn: 181340
2013-05-08 02:35:34 +08:00
m_thread_list_real.Destroy();
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();
The Threads created when requesting extended backtraces need to be owned by something; add a new ExtendedThreadList to Process where they can be retained for the duration of a public stop. <rdar://problem/15314068> llvm-svn: 194367
2013-11-11 13:20:44 +08:00
m_extended_thread_list.Destroy();
Add new Queue, QueueItem, Queuelist, SBQueue, SBQueueItem classes to represent libdispatch aka Grand Central Dispatch (GCD) queues. Still fleshing out the documentation and testing of these but the overall API is settling down so it's a good time to check it in. <rdar://problem/15600370> llvm-svn: 197190
2013-12-13 08:29:16 +08:00
m_queue_list.Clear();
m_queue_list_stop_id = 0;
<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();
LLDB AddressSanitizer instrumentation runtime plugin, breakpint on error and report data extraction Reviewed at http://reviews.llvm.org/D5592 This patch gives LLDB some ability to interact with AddressSanitizer runtime library, on top of what we already have (historical memory stack traces provided by ASan). Namely, that's the ability to stop on an error caught by ASan, and access the report information that are associated with it. The report information is also exposed into SB API. More precisely this patch... adds a new plugin type, InstrumentationRuntime, which should serve as a generic superclass for other instrumentation runtime libraries, these plugins get notified when modules are loaded, so they get a chance to "activate" when a specific dynamic library is loaded an instance of this plugin type, AddressSanitizerRuntime, which activates itself when it sees the ASan dynamic library or founds ASan statically linked in the executable adds a collection of these plugins into the Process class AddressSanitizerRuntime sets an internal breakpoint on __asan::AsanDie(), and when this breakpoint gets hit, it retrieves the report information from ASan this breakpoint is then exposed as a new StopReason, eStopReasonInstrumentation, with a new StopInfo subclass, InstrumentationRuntimeStopInfo the StopInfo superclass is extended with a m_extended_info field (it's a StructuredData::ObjectSP), that can hold arbitrary JSON-like data, which is the way the new plugin provides the report data the "thread info" command now accepts a "-s" flag that prints out the JSON data of a stop reason (same way the "-j" flag works now) SBThread has a new API, GetStopReasonExtendedInfoAsJSON, which dumps the JSON string into a SBStream adds a test case for all of this I plan to also get rid of the original ASan plugin (memory history stack traces) and use an instance of AddressSanitizerRuntime for that purpose. Kuba llvm-svn: 219546
2014-10-11 07:43:03 +08:00
m_instrumentation_runtimes.clear();
<rdar://problem/10732738> Release more stuff in Process::Destroy(). llvm-svn: 148597
2012-01-21 07:08:34 +08:00
m_next_event_action_ap.reset();
Handle thumb IT instructions correctly all the time. The issue with Thumb IT (if/then) instructions is the IT instruction preceeds up to four instructions that are made conditional. If a breakpoint is placed on one of the conditional instructions, the instruction either needs to match the thumb opcode size (2 or 4 bytes) or a BKPT instruction needs to be used as these are always unconditional (even in a IT instruction). If BKPT instructions are used, then we might end up stopping on an instruction that won't get executed. So if we do stop at a BKPT instruction, we need to continue if the condition is not true. When using the BKPT isntructions are easy in that you don't need to detect the size of the breakpoint that needs to be used when setting a breakpoint even in a thumb IT instruction. The bad part is you will now always stop at the opcode location and let LLDB determine if it should auto-continue. If the BKPT instruction is used, the BKPT that is used for ARM code should be something that also triggers the BKPT instruction in Thumb in case you set a breakpoint in the middle of code and the code is actually Thumb code. A value of 0xE120BE70 will work since the lower 16 bits being 0xBE70 happens to be a Thumb BKPT instruction. The alternative is to use trap or illegal instructions that the kernel will translate into breakpoint hits. On Mac this was 0xE7FFDEFE for ARM and 0xDEFE for Thumb. The darwin kernel currently doesn't recognize any 32 bit Thumb instruction as a instruction that will get turned into a breakpoint exception (EXC_BREAKPOINT), so we had to use the BKPT instruction on Mac. The linux kernel recognizes a 16 and a 32 bit instruction as valid thumb breakpoint opcodes. The benefit of using 16 or 32 bit instructions is you don't stop on opcodes in a IT block when the condition doesn't match. To further complicate things, single stepping on ARM is often implemented by modifying the BCR/BVR registers and setting the processor to stop when the PC is not equal to the current value. This means single stepping is another way the ARM target can stop on instructions that won't get executed. This patch does the following: 1 - Fix the internal debugserver for Apple to use the BKPT instruction for ARM and Thumb 2 - Fix LLDB to catch when we stop in the middle of a Thumb IT instruction and continue if we stop at an instruction that won't execute 3 - Fixes this in a way that will work for any target on any platform as long as it is ARM/Thumb 4 - Adds a patch for ignoring conditions that don't match when in ARM mode (see below) This patch also provides the code that implements the same thing for ARM instructions, though it is disabled for now. The ARM patch will check the condition of the instruction in ARM mode and continue if the condition isn't true (and therefore the instruction would not be executed). Again, this is not enable, but the code for it has been added. <rdar://problem/19145455> llvm-svn: 223851
2014-12-10 07:31:02 +08:00
m_stop_info_override_callback = NULL;
I finally found the strong reference that was keeping all lldb_private::Process instances from ever destroying themselves: ProcessModID.m_mod_id was holding onto the last stop event with ProcessModID::SetStopEventForLastNaturalStopID(EventSP). This is a bad idea because ProcessEventData contains a strong refereence to the process. This is now fixed by calling ProcessModID::SetStopEventForLastNaturalStopID(EventSP()) to clear this event in Process::SetExitStatus() and in Process::Finalize(). This was the original cause of the file descriptor leaks that would cause the test suite to die after running a few hundred processes since no process would ever get destroyed and the communication channel in ProcessGDBRemote and the ProcessIOHandler would never close their pipes. This process leak was previously worked around by closing the pipes when the communication channel was disconnected. This was found by using "ptr_refs" from the heap.py in the lldb.macosx.heap module. It was able to find all strong references to the Process and helped me to figure out who was holding this extra reference. llvm-svn: 238392
2015-05-28 11:24:30 +08:00
// Clear the last natural stop ID since it has a strong
// reference to this process
m_mod_id.SetStopEventForLastNaturalStopID(EventSP());
<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();
Use flag instead of rwlock state to track process running state LLDB requires that the inferior process be stopped before, and remain stopped during, certain accesses to process state. Previously this was achieved with a POSIX rwlock which had a write lock taken for the duration that the process was running, and released when the process was stopped. Any access to process state was performed with a read lock held. However, POSIX requires that pthread_rwlock_unlock() be called from the same thread as pthread_rwlock_wrlock(), and lldb needs to stop and start the process from different threads. Violating this constraint is technically undefined behaviour, although as it happens Linux and Darwin result in the unlock proceeding in this case. FreeBSD follows POSIX more strictly, and the unlock would fail, resulting in a hang later upon the next attempt to take the lock. All read lock consumers use ReadTryLock() and handle failure to obtain the lock (typically by logging an error "process is running"). Thus, instead of using the lock state itself to track the running state, this change adds an explicit m_running flag. ReadTryLock tests the flag, and if the process is not running it returns with the read lock held. WriteLock and WriteTryLock are renamed to SetRunning and TrySetRunning, and (if successful) they set m_running with the lock held. This way, read consumers can determine if the process is running and act appropriately, and write consumers are still held off from starting the process if read consumers are active. Note that with this change there are still some curious access patterns, such as calling WriteUnlock / SetStopped twice in a row, and there's no protection from multiple threads trying to simultaneously start the process. In practice this does not seem to be a problem, and was exposing other undefined POSIX behaviour prior to this change. llvm-svn: 187377
2013-07-30 04:58:06 +08:00
m_public_run_lock.TrySetRunning(); // This will do nothing if already locked
m_public_run_lock.SetStopped();
m_private_run_lock.TrySetRunning(); // This will do nothing if already locked
m_private_run_lock.SetStopped();
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;
}
Improve LLDB prompt handling Summary: There is an issue in lldb where the command prompt can appear at the wrong time. The partial fix we have in for this is not working all the time and is introducing unnecessary delays. This change does: - Change Process:SyncIOHandler to use integer start id's for synchronization to avoid it being confused by quick start-stop cycles. I picked this up from a suggested patch by Greg to lldb-dev. - coordinates printing of asynchronous text with the iohandlers. This is also based on a (different) Greg's patch, but I have added stronger synchronization to it to avoid races. Together, these changes solve the prompt problem for me on linux (both with and without libedit). I think they should behave similarly on Mac and FreeBSD and I think they will not make matters worse for windows. Test Plan: Prompt comes out alright. All tests still pass on linux. Reviewers: clayborg, emaste, zturner Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D9823 llvm-svn: 238313
2015-05-27 20:40:32 +08:00
void
Process::SyncIOHandler (uint32_t iohandler_id, uint64_t timeout_msec)
Fix iohandler prompt race condition. This issue caused the lldb prompt to not show up in certain cases, very noticeable on Linux systems. See details on this review: http://reviews.llvm.org/D4863 And on this lldb-commits thread: http://lists.cs.uiuc.edu/pipermail/lldb-commits/Week-of-Mon-20140811/012306.html Change by Shawn Best. (Much useful help and testing by the rest of the community, thanks all!) llvm-svn: 215446
2014-08-12 22:33:19 +08:00
{
// don't sync (potentially context switch) in case where there is no process IO
Improve LLDB prompt handling Summary: There is an issue in lldb where the command prompt can appear at the wrong time. The partial fix we have in for this is not working all the time and is introducing unnecessary delays. This change does: - Change Process:SyncIOHandler to use integer start id's for synchronization to avoid it being confused by quick start-stop cycles. I picked this up from a suggested patch by Greg to lldb-dev. - coordinates printing of asynchronous text with the iohandlers. This is also based on a (different) Greg's patch, but I have added stronger synchronization to it to avoid races. Together, these changes solve the prompt problem for me on linux (both with and without libedit). I think they should behave similarly on Mac and FreeBSD and I think they will not make matters worse for windows. Test Plan: Prompt comes out alright. All tests still pass on linux. Reviewers: clayborg, emaste, zturner Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D9823 llvm-svn: 238313
2015-05-27 20:40:32 +08:00
if (! m_process_input_reader)
return;
Fix iohandler prompt race condition. This issue caused the lldb prompt to not show up in certain cases, very noticeable on Linux systems. See details on this review: http://reviews.llvm.org/D4863 And on this lldb-commits thread: http://lists.cs.uiuc.edu/pipermail/lldb-commits/Week-of-Mon-20140811/012306.html Change by Shawn Best. (Much useful help and testing by the rest of the community, thanks all!) llvm-svn: 215446
2014-08-12 22:33:19 +08:00
Improve LLDB prompt handling Summary: There is an issue in lldb where the command prompt can appear at the wrong time. The partial fix we have in for this is not working all the time and is introducing unnecessary delays. This change does: - Change Process:SyncIOHandler to use integer start id's for synchronization to avoid it being confused by quick start-stop cycles. I picked this up from a suggested patch by Greg to lldb-dev. - coordinates printing of asynchronous text with the iohandlers. This is also based on a (different) Greg's patch, but I have added stronger synchronization to it to avoid races. Together, these changes solve the prompt problem for me on linux (both with and without libedit). I think they should behave similarly on Mac and FreeBSD and I think they will not make matters worse for windows. Test Plan: Prompt comes out alright. All tests still pass on linux. Reviewers: clayborg, emaste, zturner Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D9823 llvm-svn: 238313
2015-05-27 20:40:32 +08:00
TimeValue timeout = TimeValue::Now();
timeout.OffsetWithMicroSeconds(timeout_msec*1000);
uint32_t new_iohandler_id = 0;
m_iohandler_sync.WaitForValueNotEqualTo(iohandler_id, new_iohandler_id, &timeout);
Fix iohandler prompt race condition. This issue caused the lldb prompt to not show up in certain cases, very noticeable on Linux systems. See details on this review: http://reviews.llvm.org/D4863 And on this lldb-commits thread: http://lists.cs.uiuc.edu/pipermail/lldb-commits/Week-of-Mon-20140811/012306.html Change by Shawn Best. (Much useful help and testing by the rest of the community, thanks all!) llvm-svn: 215446
2014-08-12 22:33:19 +08:00
Improve LLDB prompt handling Summary: There is an issue in lldb where the command prompt can appear at the wrong time. The partial fix we have in for this is not working all the time and is introducing unnecessary delays. This change does: - Change Process:SyncIOHandler to use integer start id's for synchronization to avoid it being confused by quick start-stop cycles. I picked this up from a suggested patch by Greg to lldb-dev. - coordinates printing of asynchronous text with the iohandlers. This is also based on a (different) Greg's patch, but I have added stronger synchronization to it to avoid races. Together, these changes solve the prompt problem for me on linux (both with and without libedit). I think they should behave similarly on Mac and FreeBSD and I think they will not make matters worse for windows. Test Plan: Prompt comes out alright. All tests still pass on linux. Reviewers: clayborg, emaste, zturner Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D9823 llvm-svn: 238313
2015-05-27 20:40:32 +08:00
Log *log(lldb_private::GetLogIfAllCategoriesSet (LIBLLDB_LOG_PROCESS));
if (log)
log->Printf("Process::%s waited for m_iohandler_sync to change from %u, new value is %u", __FUNCTION__, iohandler_id, new_iohandler_id);
Fix iohandler prompt race condition. This issue caused the lldb prompt to not show up in certain cases, very noticeable on Linux systems. See details on this review: http://reviews.llvm.org/D4863 And on this lldb-commits thread: http://lists.cs.uiuc.edu/pipermail/lldb-commits/Week-of-Mon-20140811/012306.html Change by Shawn Best. (Much useful help and testing by the rest of the community, thanks all!) llvm-svn: 215446
2014-08-12 22:33:19 +08:00
}
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
StateType
Make the "synchronous" mode actually work without race conditions. There were many issues with synchronous mode that we discovered when started to try and add a "batch" mode. There was a race condition where the event handling thread might consume events when in sync mode and other times the Process::WaitForProcessToStop() would consume them. This also led to places where the Process IO handler might or might not get popped when it needed to be. llvm-svn: 220254
2014-10-21 09:00:42 +08:00
Process::WaitForProcessToStop (const TimeValue *timeout,
EventSP *event_sp_ptr,
bool wait_always,
Listener *hijack_listener,
Recommit "Fix race during process interruption" This is a resubmit of r254403, see that commit's message for context. This fixes an issue in the original commit, where we would incorrectly interrupt the process if the interrupt request came just as we were about to send the stopped event to the public. llvm-svn: 254902
2015-12-07 20:36:52 +08:00
Stream *stream,
bool use_run_lock)
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;
Allow Process::WaitForProcessToStop to return immediately if process is already in the stopped state - By default, the above function will wait for at least one event - Set wait_always=false to make the function return immediately if the process is already stopped llvm-svn: 192301
2013-10-10 00:56:28 +08:00
Log *log(lldb_private::GetLogIfAllCategoriesSet (LIBLLDB_LOG_PROCESS));
if (log)
sweep up -Wformat warnings from gcc This is a purely mechanical change explicitly casting any parameters for printf style conversion. This cleans up the warnings emitted by gcc 4.8 on Linux. llvm-svn: 205607
2014-04-04 12:06:10 +08:00
log->Printf ("Process::%s (timeout = %p)", __FUNCTION__,
static_cast<const void*>(timeout));
Allow Process::WaitForProcessToStop to return immediately if process is already in the stopped state - By default, the above function will wait for at least one event - Set wait_always=false to make the function return immediately if the process is already stopped llvm-svn: 192301
2013-10-10 00:56:28 +08:00
if (!wait_always &&
StateIsStoppedState(state, true) &&
Formatting fix. llvm-svn: 235527
2015-04-23 01:48:24 +08:00
StateIsStoppedState(GetPrivateState(), true))
{
Allow Process::WaitForProcessToStop to return immediately if process is already in the stopped state - By default, the above function will wait for at least one event - Set wait_always=false to make the function return immediately if the process is already stopped llvm-svn: 192301
2013-10-10 00:56:28 +08:00
if (log)
log->Printf("Process::%s returning without waiting for events; process private and public states are already 'stopped'.",
__FUNCTION__);
Fix race condition with -o "process launch" on linux Summary: starting a debug session on linux with -o "process launch" lldb parameter was failing since Target::Launch (in sychronous mode) is expecting to be able to receive public process events. However, PlatformLinux did not set up event hijacking on process launch, which caused these events to be processed elsewhere and left Target::Launch hanging. This patch enables event interception in PlatformLinux (which was commented out). Upon enabling event interception, I noticed an issue, which I traced back to the inconsistent state of public run lock, which remained false even though public and private process states were "stopped". I addressed this by making sure the run lock is "stopped" upon exit from WaitForProcessToStop (which already had similar provisions for other return paths). Test Plan: This should fix the intermittent TestFormats failure we have been experiencing on Linux. Reviewers: jingham, clayborg, vharron Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D8079 llvm-svn: 231460
2015-03-06 18:52:47 +08:00
// We need to toggle the run lock as this won't get done in
// SetPublicState() if the process is hijacked.
Recommit "Fix race during process interruption" This is a resubmit of r254403, see that commit's message for context. This fixes an issue in the original commit, where we would incorrectly interrupt the process if the interrupt request came just as we were about to send the stopped event to the public. llvm-svn: 254902
2015-12-07 20:36:52 +08:00
if (hijack_listener && use_run_lock)
Fix race condition with -o "process launch" on linux Summary: starting a debug session on linux with -o "process launch" lldb parameter was failing since Target::Launch (in sychronous mode) is expecting to be able to receive public process events. However, PlatformLinux did not set up event hijacking on process launch, which caused these events to be processed elsewhere and left Target::Launch hanging. This patch enables event interception in PlatformLinux (which was commented out). Upon enabling event interception, I noticed an issue, which I traced back to the inconsistent state of public run lock, which remained false even though public and private process states were "stopped". I addressed this by making sure the run lock is "stopped" upon exit from WaitForProcessToStop (which already had similar provisions for other return paths). Test Plan: This should fix the intermittent TestFormats failure we have been experiencing on Linux. Reviewers: jingham, clayborg, vharron Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D8079 llvm-svn: 231460
2015-03-06 18:52:47 +08:00
m_public_run_lock.SetStopped();
Allow Process::WaitForProcessToStop to return immediately if process is already in the stopped state - By default, the above function will wait for at least one event - Set wait_always=false to make the function return immediately if the process is already stopped llvm-svn: 192301
2013-10-10 00:56:28 +08:00
return state;
}
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
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;
Merging the iohandler branch back into main. The many many benefits include: 1 - Input/Output/Error streams are now handled as real streams not a push style input 2 - auto completion in python embedded interpreter 3 - multi-line input for "script" and "expression" commands now allow you to edit previous/next lines using up and down arrow keys and this makes multi-line input actually a viable thing to use 4 - it is now possible to use curses to drive LLDB (please try the "gui" command) We will need to deal with and fix any buildbot failures and tests and arise now that input/output and error are correctly hooked up in all cases. llvm-svn: 200263
2014-01-28 07:43:24 +08:00
state = WaitForStateChangedEvents (timeout, event_sp, hijack_listener);
<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;
Make the "synchronous" mode actually work without race conditions. There were many issues with synchronous mode that we discovered when started to try and add a "batch" mode. There was a race condition where the event handling thread might consume events when in sync mode and other times the Process::WaitForProcessToStop() would consume them. This also led to places where the Process IO handler might or might not get popped when it needed to be. llvm-svn: 220254
2014-10-21 09:00:42 +08:00
bool pop_process_io_handler = hijack_listener != NULL;
Process::HandleProcessStateChangedEvent (event_sp, stream, pop_process_io_handler);
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:
Merging the iohandler branch back into main. The many many benefits include: 1 - Input/Output/Error streams are now handled as real streams not a push style input 2 - auto completion in python embedded interpreter 3 - multi-line input for "script" and "expression" commands now allow you to edit previous/next lines using up and down arrow keys and this makes multi-line input actually a viable thing to use 4 - it is now possible to use curses to drive LLDB (please try the "gui" command) We will need to deal with and fix any buildbot failures and tests and arise now that input/output and error are correctly hooked up in all cases. llvm-svn: 200263
2014-01-28 07:43:24 +08:00
// We need to toggle the run lock as this won't get done in
// SetPublicState() if the process is hijacked.
Recommit "Fix race during process interruption" This is a resubmit of r254403, see that commit's message for context. This fixes an issue in the original commit, where we would incorrectly interrupt the process if the interrupt request came just as we were about to send the stopped event to the public. llvm-svn: 254902
2015-12-07 20:36:52 +08:00
if (hijack_listener && use_run_lock)
Merging the iohandler branch back into main. The many many benefits include: 1 - Input/Output/Error streams are now handled as real streams not a push style input 2 - auto completion in python embedded interpreter 3 - multi-line input for "script" and "expression" commands now allow you to edit previous/next lines using up and down arrow keys and this makes multi-line input actually a viable thing to use 4 - it is now possible to use curses to drive LLDB (please try the "gui" command) We will need to deal with and fix any buildbot failures and tests and arise now that input/output and error are correctly hooked up in all cases. llvm-svn: 200263
2014-01-28 07:43:24 +08:00
m_public_run_lock.SetStopped();
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
return state;
case eStateStopped:
if (Process::ProcessEventData::GetRestartedFromEvent(event_sp.get()))
continue;
else
Merging the iohandler branch back into main. The many many benefits include: 1 - Input/Output/Error streams are now handled as real streams not a push style input 2 - auto completion in python embedded interpreter 3 - multi-line input for "script" and "expression" commands now allow you to edit previous/next lines using up and down arrow keys and this makes multi-line input actually a viable thing to use 4 - it is now possible to use curses to drive LLDB (please try the "gui" command) We will need to deal with and fix any buildbot failures and tests and arise now that input/output and error are correctly hooked up in all cases. llvm-svn: 200263
2014-01-28 07:43:24 +08:00
{
// We need to toggle the run lock as this won't get done in
// SetPublicState() if the process is hijacked.
Recommit "Fix race during process interruption" This is a resubmit of r254403, see that commit's message for context. This fixes an issue in the original commit, where we would incorrectly interrupt the process if the interrupt request came just as we were about to send the stopped event to the public. llvm-svn: 254902
2015-12-07 20:36:52 +08:00
if (hijack_listener && use_run_lock)
Merging the iohandler branch back into main. The many many benefits include: 1 - Input/Output/Error streams are now handled as real streams not a push style input 2 - auto completion in python embedded interpreter 3 - multi-line input for "script" and "expression" commands now allow you to edit previous/next lines using up and down arrow keys and this makes multi-line input actually a viable thing to use 4 - it is now possible to use curses to drive LLDB (please try the "gui" command) We will need to deal with and fix any buildbot failures and tests and arise now that input/output and error are correctly hooked up in all cases. llvm-svn: 200263
2014-01-28 07:43:24 +08:00
m_public_run_lock.SetStopped();
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
return state;
Merging the iohandler branch back into main. The many many benefits include: 1 - Input/Output/Error streams are now handled as real streams not a push style input 2 - auto completion in python embedded interpreter 3 - multi-line input for "script" and "expression" commands now allow you to edit previous/next lines using up and down arrow keys and this makes multi-line input actually a viable thing to use 4 - it is now possible to use curses to drive LLDB (please try the "gui" command) We will need to deal with and fix any buildbot failures and tests and arise now that input/output and error are correctly hooked up in all cases. llvm-svn: 200263
2014-01-28 07:43: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
default:
continue;
}
}
return state;
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
Make the "synchronous" mode actually work without race conditions. There were many issues with synchronous mode that we discovered when started to try and add a "batch" mode. There was a race condition where the event handling thread might consume events when in sync mode and other times the Process::WaitForProcessToStop() would consume them. This also led to places where the Process IO handler might or might not get popped when it needed to be. llvm-svn: 220254
2014-10-21 09:00:42 +08:00
bool
Process::HandleProcessStateChangedEvent (const EventSP &event_sp,
Stream *stream,
bool &pop_process_io_handler)
{
const bool handle_pop = pop_process_io_handler == true;
pop_process_io_handler = false;
ProcessSP process_sp = Process::ProcessEventData::GetProcessFromEvent(event_sp.get());
if (!process_sp)
return false;
StateType event_state = Process::ProcessEventData::GetStateFromEvent (event_sp.get());
if (event_state == eStateInvalid)
return false;
switch (event_state)
{
case eStateInvalid:
case eStateUnloaded:
case eStateAttaching:
case eStateLaunching:
case eStateStepping:
case eStateDetached:
{
if (stream)
stream->Printf ("Process %" PRIu64 " %s\n",
process_sp->GetID(),
StateAsCString (event_state));
if (event_state == eStateDetached)
pop_process_io_handler = true;
}
break;
Make the platform process connect path less chatty. Summary: If a stream contains an empty string, no need to append it to the output (otherwise we end up with a blank line). Also, no need to print a status message when the state changes to connected, as this string brings no information -- "Process 0" does not mean anything to the user, and the process being connected has no meaning either. Test Plan: Connect to a remote linux platform mode daemon with `platform select remote-linux` followed by `platform connect ...`, create a target and run it, observe the output. Also, run the full test suite (dosep.py). Before: (lldb) [...] connect, etc. (lldb) r Process 0 connected Process 5635 launched: '/Users/sas/Source/test' (x86_64) Process 5635 stopped After: (lldb) [...] connect, etc. (lldb) r Process 5635 launched: '/Users/sas/Source/test' (x86_64) Process 5635 stopped Reviewers: tfiala, vharron, clayborg Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D6593 llvm-svn: 224188
2014-12-13 13:23:51 +08:00
case eStateConnected:
Make the "synchronous" mode actually work without race conditions. There were many issues with synchronous mode that we discovered when started to try and add a "batch" mode. There was a race condition where the event handling thread might consume events when in sync mode and other times the Process::WaitForProcessToStop() would consume them. This also led to places where the Process IO handler might or might not get popped when it needed to be. llvm-svn: 220254
2014-10-21 09:00:42 +08:00
case eStateRunning:
// Don't be chatty when we run...
break;
case eStateExited:
if (stream)
process_sp->GetStatus(*stream);
pop_process_io_handler = true;
break;
case eStateStopped:
case eStateCrashed:
case eStateSuspended:
// Make sure the program hasn't been auto-restarted:
if (Process::ProcessEventData::GetRestartedFromEvent (event_sp.get()))
{
if (stream)
{
size_t num_reasons = Process::ProcessEventData::GetNumRestartedReasons(event_sp.get());
if (num_reasons > 0)
{
// FIXME: Do we want to report this, or would that just be annoyingly chatty?
if (num_reasons == 1)
{
const char *reason = Process::ProcessEventData::GetRestartedReasonAtIndex (event_sp.get(), 0);
stream->Printf ("Process %" PRIu64 " stopped and restarted: %s\n",
process_sp->GetID(),
reason ? reason : "<UNKNOWN REASON>");
}
else
{
stream->Printf ("Process %" PRIu64 " stopped and restarted, reasons:\n",
process_sp->GetID());
for (size_t i = 0; i < num_reasons; i++)
{
const char *reason = Process::ProcessEventData::GetRestartedReasonAtIndex (event_sp.get(), i);
stream->Printf("\t%s\n", reason ? reason : "<UNKNOWN REASON>");
}
}
}
}
}
else
{
// Lock the thread list so it doesn't change on us, this is the scope for the locker:
{
ThreadList &thread_list = process_sp->GetThreadList();
Mutex::Locker locker (thread_list.GetMutex());
ThreadSP curr_thread (thread_list.GetSelectedThread());
ThreadSP thread;
StopReason curr_thread_stop_reason = eStopReasonInvalid;
if (curr_thread)
curr_thread_stop_reason = curr_thread->GetStopReason();
if (!curr_thread ||
!curr_thread->IsValid() ||
curr_thread_stop_reason == eStopReasonInvalid ||
curr_thread_stop_reason == eStopReasonNone)
{
// Prefer a thread that has just completed its plan over another thread as current thread.
ThreadSP plan_thread;
ThreadSP other_thread;
Don't select a thread that stopped for a signal that was not set to stop - there must be some other thread that stopped for a more interesting reason. <rdar://problem/19943567> llvm-svn: 241650
2015-07-08 08:06:30 +08:00
Make the "synchronous" mode actually work without race conditions. There were many issues with synchronous mode that we discovered when started to try and add a "batch" mode. There was a race condition where the event handling thread might consume events when in sync mode and other times the Process::WaitForProcessToStop() would consume them. This also led to places where the Process IO handler might or might not get popped when it needed to be. llvm-svn: 220254
2014-10-21 09:00:42 +08:00
const size_t num_threads = thread_list.GetSize();
size_t i;
for (i = 0; i < num_threads; ++i)
{
thread = thread_list.GetThreadAtIndex(i);
StopReason thread_stop_reason = thread->GetStopReason();
switch (thread_stop_reason)
{
case eStopReasonInvalid:
case eStopReasonNone:
break;
Don't select a thread that stopped for a signal that was not set to stop - there must be some other thread that stopped for a more interesting reason. <rdar://problem/19943567> llvm-svn: 241650
2015-07-08 08:06:30 +08:00
case eStopReasonSignal:
{
// Don't select a signal thread if we weren't going to stop at that
// signal. We have to have had another reason for stopping here, and
// the user doesn't want to see this thread.
uint64_t signo = thread->GetStopInfo()->GetValue();
Refactor Unix signals. Summary: - Consolidate Unix signals selection in UnixSignals. - Make Unix signals available from platform. - Add jSignalsInfo packet to retrieve Unix signals from remote platform. - Get a copy of the platform signal for each remote process. - Update SB API for signals. - Update signal utility in test suite. Reviewers: ovyalov, clayborg Subscribers: chaoren, jingham, labath, emaste, tberghammer, lldb-commits Differential Revision: http://reviews.llvm.org/D11094 llvm-svn: 242101
2015-07-14 09:09:28 +08:00
if (process_sp->GetUnixSignals()->GetShouldStop(signo))
Don't select a thread that stopped for a signal that was not set to stop - there must be some other thread that stopped for a more interesting reason. <rdar://problem/19943567> llvm-svn: 241650
2015-07-08 08:06:30 +08:00
{
if (!other_thread)
other_thread = thread;
}
break;
}
Make the "synchronous" mode actually work without race conditions. There were many issues with synchronous mode that we discovered when started to try and add a "batch" mode. There was a race condition where the event handling thread might consume events when in sync mode and other times the Process::WaitForProcessToStop() would consume them. This also led to places where the Process IO handler might or might not get popped when it needed to be. llvm-svn: 220254
2014-10-21 09:00:42 +08:00
case eStopReasonTrace:
case eStopReasonBreakpoint:
case eStopReasonWatchpoint:
case eStopReasonException:
case eStopReasonExec:
case eStopReasonThreadExiting:
case eStopReasonInstrumentation:
if (!other_thread)
other_thread = thread;
break;
case eStopReasonPlanComplete:
if (!plan_thread)
plan_thread = thread;
break;
}
}
if (plan_thread)
thread_list.SetSelectedThreadByID (plan_thread->GetID());
else if (other_thread)
thread_list.SetSelectedThreadByID (other_thread->GetID());
else
{
if (curr_thread && curr_thread->IsValid())
thread = curr_thread;
else
thread = thread_list.GetThreadAtIndex(0);
if (thread)
thread_list.SetSelectedThreadByID (thread->GetID());
}
}
}
// Drop the ThreadList mutex by here, since GetThreadStatus below might have to run code,
// e.g. for Data formatters, and if we hold the ThreadList mutex, then the process is going to
// have a hard time restarting the process.
if (stream)
{
Debugger &debugger = process_sp->GetTarget().GetDebugger();
if (debugger.GetTargetList().GetSelectedTarget().get() == &process_sp->GetTarget())
{
const bool only_threads_with_stop_reason = true;
const uint32_t start_frame = 0;
const uint32_t num_frames = 1;
const uint32_t num_frames_with_source = 1;
process_sp->GetStatus(*stream);
process_sp->GetThreadStatus (*stream,
only_threads_with_stop_reason,
start_frame,
num_frames,
num_frames_with_source);
}
else
{
uint32_t target_idx = debugger.GetTargetList().GetIndexOfTarget(process_sp->GetTarget().shared_from_this());
if (target_idx != UINT32_MAX)
stream->Printf ("Target %d: (", target_idx);
else
stream->Printf ("Target <unknown index>: (");
process_sp->GetTarget().Dump (stream, eDescriptionLevelBrief);
stream->Printf (") stopped.\n");
}
}
// Pop the process IO handler
pop_process_io_handler = true;
}
break;
}
if (handle_pop && pop_process_io_handler)
process_sp->PopProcessIOHandler();
return true;
}
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
StateType
Fix Clang-tidy modernize-use-override warnings in source/Target; other minor fixes. llvm-svn: 251134
2015-10-24 02:39:37 +08:00
Process::WaitForState(const TimeValue *timeout,
const StateType *match_states,
const uint32_t num_match_states)
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
{
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;
Merging the iohandler branch back into main. The many many benefits include: 1 - Input/Output/Error streams are now handled as real streams not a push style input 2 - auto completion in python embedded interpreter 3 - multi-line input for "script" and "expression" commands now allow you to edit previous/next lines using up and down arrow keys and this makes multi-line input actually a viable thing to use 4 - it is now possible to use curses to drive LLDB (please try the "gui" command) We will need to deal with and fix any buildbot failures and tests and arise now that input/output and error are correctly hooked up in all cases. llvm-svn: 200263
2014-01-28 07:43:24 +08:00
state = WaitForStateChangedEvents (timeout, event_sp, NULL);
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
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();
}
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
StateType
Merging the iohandler branch back into main. The many many benefits include: 1 - Input/Output/Error streams are now handled as real streams not a push style input 2 - auto completion in python embedded interpreter 3 - multi-line input for "script" and "expression" commands now allow you to edit previous/next lines using up and down arrow keys and this makes multi-line input actually a viable thing to use 4 - it is now possible to use curses to drive LLDB (please try the "gui" command) We will need to deal with and fix any buildbot failures and tests and arise now that input/output and error are correctly hooked up in all cases. llvm-svn: 200263
2014-01-28 07:43:24 +08:00
Process::WaitForStateChangedEvents (const TimeValue *timeout, EventSP &event_sp, Listener *hijack_listener)
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)
sweep up -Wformat warnings from gcc This is a purely mechanical change explicitly casting any parameters for printf style conversion. This cleans up the warnings emitted by gcc 4.8 on Linux. llvm-svn: 205607
2014-04-04 12:06:10 +08:00
log->Printf ("Process::%s (timeout = %p, event_sp)...", __FUNCTION__,
static_cast<const void*>(timeout));
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
Merging the iohandler branch back into main. The many many benefits include: 1 - Input/Output/Error streams are now handled as real streams not a push style input 2 - auto completion in python embedded interpreter 3 - multi-line input for "script" and "expression" commands now allow you to edit previous/next lines using up and down arrow keys and this makes multi-line input actually a viable thing to use 4 - it is now possible to use curses to drive LLDB (please try the "gui" command) We will need to deal with and fix any buildbot failures and tests and arise now that input/output and error are correctly hooked up in all cases. llvm-svn: 200263
2014-01-28 07:43:24 +08:00
Listener *listener = hijack_listener;
if (listener == NULL)
listener = &m_listener;
sweep up -Wformat warnings from gcc This is a purely mechanical change explicitly casting any parameters for printf style conversion. This cleans up the warnings emitted by gcc 4.8 on Linux. llvm-svn: 205607
2014-04-04 12:06:10 +08:00
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
StateType state = eStateInvalid;
Merging the iohandler branch back into main. The many many benefits include: 1 - Input/Output/Error streams are now handled as real streams not a push style input 2 - auto completion in python embedded interpreter 3 - multi-line input for "script" and "expression" commands now allow you to edit previous/next lines using up and down arrow keys and this makes multi-line input actually a viable thing to use 4 - it is now possible to use curses to drive LLDB (please try the "gui" command) We will need to deal with and fix any buildbot failures and tests and arise now that input/output and error are correctly hooked up in all cases. llvm-svn: 200263
2014-01-28 07:43:24 +08:00
if (listener->WaitForEventForBroadcasterWithType (timeout,
this,
eBroadcastBitStateChanged | eBroadcastBitInterrupt,
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",
sweep up -Wformat warnings from gcc This is a purely mechanical change explicitly casting any parameters for printf style conversion. This cleans up the warnings emitted by gcc 4.8 on Linux. llvm-svn: 205607
2014-04-04 12:06:10 +08:00
__FUNCTION__, static_cast<const void*>(timeout),
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
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)
sweep up -Wformat warnings from gcc This is a purely mechanical change explicitly casting any parameters for printf style conversion. This cleans up the warnings emitted by gcc 4.8 on Linux. llvm-svn: 205607
2014-04-04 12:06:10 +08:00
log->Printf ("Process::%s (timeout = %p, event_sp)...", __FUNCTION__,
static_cast<const void*>(timeout));
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
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)
sweep up -Wformat warnings from gcc This is a purely mechanical change explicitly casting any parameters for printf style conversion. This cleans up the warnings emitted by gcc 4.8 on Linux. llvm-svn: 205607
2014-04-04 12:06:10 +08:00
log->Printf ("Process::%s (timeout = %p, event_sp) => %s",
__FUNCTION__, static_cast<const void *>(timeout),
state == eStateInvalid ? "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)
sweep up -Wformat warnings from gcc This is a purely mechanical change explicitly casting any parameters for printf style conversion. This cleans up the warnings emitted by gcc 4.8 on Linux. llvm-svn: 205607
2014-04-04 12:06:10 +08:00
log->Printf ("Process::%s (timeout = %p, event_sp)...", __FUNCTION__,
static_cast<const void*>(timeout));
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
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 ()
{
use std::atomic<> to protect variables being accessed by multiple threads There are several places where multiple threads are accessing the same variables simultaneously without any kind of protection. I propose using std::atomic<> to make it safer. I did a special build of lldb, using the google tool 'thread sanitizer' which identified many cases of multiple threads accessing the same memory. std::atomic is low overhead and does not use any locks for simple types such as int/bool. See http://reviews.llvm.org/D5302 for more details. Change by Shawn Best. llvm-svn: 217818
2014-09-16 04:07:33 +08:00
Mutex::Locker locker (m_exit_status_mutex);
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
if (m_public_state.GetValue() == eStateExited)
return m_exit_status;
return -1;
}
const char *
Process::GetExitDescription ()
{
use std::atomic<> to protect variables being accessed by multiple threads There are several places where multiple threads are accessing the same variables simultaneously without any kind of protection. I propose using std::atomic<> to make it safer. I did a special build of lldb, using the google tool 'thread sanitizer' which identified many cases of multiple threads accessing the same memory. std::atomic is low overhead and does not use any locks for simple types such as int/bool. See http://reviews.llvm.org/D5302 for more details. Change by Shawn Best. llvm-svn: 217818
2014-09-16 04:07:33 +08:00
Mutex::Locker locker (m_exit_status_mutex);
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
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)
{
Fix a race condition where 2 threads might try to call Process::SetExitStatus() at the same time. The problem was the mutex was only protecting the setting of m_exit_string and m_exit_string, but this function relies on the m_private_state being set to eStateExited in order to prevent more than 1 client setting the exit status. We want to only allow the first caller to succeed. On MacOSX we have a thread that reaps the process we are debugging, and we also have a thread that monitors the debugserver process. When a process exists, the ProcessGDBRemote::AsyncThread() would set the exit status to the correct value and then another thread would reap the debugserver process and they would often both end up in Process::SetExitStatus() at the same time. With the mutex at the top we allow all variables to be set and the m_private_state to be set to eStateExited _before_ the other thread (debugserver reaped) can try to set th exist status to -1 and "lost connection to debugserver" being set as the exit status. This was probably an issue for lldb-server as well and could very well cleanup some tests that might have been expecting a specific exit status from the process being debugged. llvm-svn: 238794
2015-06-02 07:14:09 +08:00
// Use a mutex to protect setting the exit status.
Mutex::Locker locker (m_exit_status_mutex);
<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
}
use std::atomic<> to protect variables being accessed by multiple threads There are several places where multiple threads are accessing the same variables simultaneously without any kind of protection. I propose using std::atomic<> to make it safer. I did a special build of lldb, using the google tool 'thread sanitizer' which identified many cases of multiple threads accessing the same memory. std::atomic is low overhead and does not use any locks for simple types such as int/bool. See http://reviews.llvm.org/D5302 for more details. Change by Shawn Best. llvm-svn: 217818
2014-09-16 04:07:33 +08:00
Fix a race condition where 2 threads might try to call Process::SetExitStatus() at the same time. The problem was the mutex was only protecting the setting of m_exit_string and m_exit_string, but this function relies on the m_private_state being set to eStateExited in order to prevent more than 1 client setting the exit status. We want to only allow the first caller to succeed. On MacOSX we have a thread that reaps the process we are debugging, and we also have a thread that monitors the debugserver process. When a process exists, the ProcessGDBRemote::AsyncThread() would set the exit status to the correct value and then another thread would reap the debugserver process and they would often both end up in Process::SetExitStatus() at the same time. With the mutex at the top we allow all variables to be set and the m_private_state to be set to eStateExited _before_ the other thread (debugserver reaped) can try to set th exist status to -1 and "lost connection to debugserver" being set as the exit status. This was probably an issue for lldb-server as well and could very well cleanup some tests that might have been expecting a specific exit status from the process being debugged. llvm-svn: 238794
2015-06-02 07:14:09 +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
Fix rare failure in TestProcessIO Summary: There was a race condition in Process class, where we would not wait for process stdout to propagate fully before we would shut down the connection (repro case: slow down the stdio thread by placing a sleep right at the end of the while loop in Communication::ReadThread). The Process class already tried to solve this problem by synchronizing with the read thread in Process::ShouldBroadcastEvent, but unfortunately the connection got closed before that in Process::SetExitStatus. I solve this issue by delaying the connection shutdown until we get a chance to process the event and synchronize. Alternatively, I could have moved the synchronization point to an earlier point in SetExitStatus, but it seems safer to delay the shutdown until other things get a chance to notice the process has exited. Reviewers: clayborg, ovyalov Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D12558 llvm-svn: 246753
2015-09-03 17:30:17 +08:00
// When we exit, we don't need the input reader anymore
Did some cleanup to stop us from leaking Pipe file descriptors. The main issue was the Communication::Disconnect() was calling its Connection::Disconnect() but this wouldn't release the pipes that the ConnectionFileDescriptor was using. We also have someone that is holding a strong reference to the Process so that when you re-run, target replaces its m_process_sp, but it doesn't get destructed because someone has a strong reference to it. I need to track that down. But, even if we have a strong reference to the a process that is outstanding, we need to call Process::Finalize() to have it release as much of its resources as possible to avoid memory bloat. Removed the ProcessGDBRemote::SetExitStatus() override and replaced it with ProcessGDBRemote::DidExit(). Now we aren't leaking file descriptors and the stand alone test suite should run much better. llvm-svn: 238089
2015-05-23 11:54:53 +08:00
if (m_process_input_reader)
{
m_process_input_reader->SetIsDone(true);
m_process_input_reader->Cancel();
m_process_input_reader.reset();
}
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
I finally found the strong reference that was keeping all lldb_private::Process instances from ever destroying themselves: ProcessModID.m_mod_id was holding onto the last stop event with ProcessModID::SetStopEventForLastNaturalStopID(EventSP). This is a bad idea because ProcessEventData contains a strong refereence to the process. This is now fixed by calling ProcessModID::SetStopEventForLastNaturalStopID(EventSP()) to clear this event in Process::SetExitStatus() and in Process::Finalize(). This was the original cause of the file descriptor leaks that would cause the test suite to die after running a few hundred processes since no process would ever get destroyed and the communication channel in ProcessGDBRemote and the ProcessIOHandler would never close their pipes. This process leak was previously worked around by closing the pipes when the communication channel was disconnected. This was found by using "ptr_refs" from the heap.py in the lldb.macosx.heap module. It was able to find all strong references to the Process and helped me to figure out who was holding this extra reference. llvm-svn: 238392
2015-05-28 11:24:30 +08:00
// Clear the last natural stop ID since it has a strong
// reference to this process
m_mod_id.SetStopEventForLastNaturalStopID(EventSP());
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);
Did some cleanup to stop us from leaking Pipe file descriptors. The main issue was the Communication::Disconnect() was calling its Connection::Disconnect() but this wouldn't release the pipes that the ConnectionFileDescriptor was using. We also have someone that is holding a strong reference to the Process so that when you re-run, target replaces its m_process_sp, but it doesn't get destructed because someone has a strong reference to it. I need to track that down. But, even if we have a strong reference to the a process that is outstanding, we need to call Process::Finalize() to have it release as much of its resources as possible to avoid memory bloat. Removed the ProcessGDBRemote::SetExitStatus() override and replaced it with ProcessGDBRemote::DidExit(). Now we aren't leaking file descriptors and the stand alone test suite should run much better. llvm-svn: 238089
2015-05-23 11:54:53 +08:00
// Allow subclasses to do some cleanup
DidExit ();
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 true;
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
Add support for the new (added last week) llvm::Triple::WatchOS and ::TvOS in places where we check for Triple::IOS. They're mostly the same as far as lldb is conerned. . Also add a base cass implementation for Process::IsAlive - Greg added this last year but it didn't get upstreamed. llvm-svn: 252227
2015-11-06 07:03:44 +08:00
bool
Process::IsAlive ()
{
switch (m_private_state.GetValue())
{
case eStateConnected:
case eStateAttaching:
case eStateLaunching:
case eStateStopped:
case eStateRunning:
case eStateStepping:
case eStateCrashed:
case eStateSuspended:
return true;
Placate MVSC after my last commit. Zachary introduced the 'default' case explicitly to placate a warning in the Microsoft compiler but that broke clang with -Werror. The new code should keep both compilers happy. llvm-svn: 258212
2016-01-20 06:47:51 +08:00
default:
return false;
Add support for the new (added last week) llvm::Triple::WatchOS and ::TvOS in places where we check for Triple::IOS. They're mostly the same as far as lldb is conerned. . Also add a base cass implementation for Process::IsAlive - Greg added this last year but it didn't get upstreamed. llvm-svn: 252227
2015-11-06 07:03:44 +08:00
}
}
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
Fix typos. llvm-svn: 212132
2014-07-02 05:22:11 +08:00
// the current host. The child process exits, the process will be
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
// 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)
Refactor Unix signals. Summary: - Consolidate Unix signals selection in UnixSignals. - Make Unix signals available from platform. - Add jSignalsInfo packet to retrieve Unix signals from remote platform. - Get a copy of the platform signal for each remote process. - Update SB API for signals. - Update signal utility in test suite. Reviewers: ovyalov, clayborg Subscribers: chaoren, jingham, labath, emaste, tberghammer, lldb-commits Differential Revision: http://reviews.llvm.org/D11094 llvm-svn: 242101
2015-07-14 09:09:28 +08:00
signal_cstr = process_sp->GetUnixSignals()->GetSignalAsCString(signo);
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
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
Reinstating r181091 and r181106 with fix for Linux regressions. llvm-svn: 181340
2013-05-08 02:35:34 +08:00
ThreadList &old_thread_list = m_thread_list;
ThreadList real_thread_list(this);
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
Reinstating r181091 and r181106 with fix for Linux regressions. llvm-svn: 181340
2013-05-08 02:35:34 +08:00
if (UpdateThreadList (m_thread_list_real, real_thread_list))
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
{
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.
Fix race during process detach Summary: The code which was preventing the usage of the OS plugin while detach is in progress also prevented us to update the thread list correctly. This resulted in an empty thread list, which confused the detaching logic. Change the condition do only do what it says (disable the usage of the OS plugin). Reviewers: clayborg, jingham Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D14201 llvm-svn: 251932
2015-11-04 00:05:18 +08:00
OperatingSystem *os = GetOperatingSystem ();
if (os && !m_destroy_in_process)
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
{
Fix race during process detach Summary: The code which was preventing the usage of the OS plugin while detach is in progress also prevented us to update the thread list correctly. This resulted in an empty thread list, which confused the detaching logic. Change the condition do only do what it says (disable the usage of the OS plugin). Reviewers: clayborg, jingham Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D14201 llvm-svn: 251932
2015-11-04 00:05:18 +08:00
// Clear any old backing threads where memory threads might have been
// backed by actual threads from the lldb_private::Process subclass
size_t num_old_threads = old_thread_list.GetSize(false);
for (size_t i=0; i<num_old_threads; ++i)
old_thread_list.GetThreadAtIndex(i, false)->ClearBackingThread();
// Turn off dynamic types to ensure we don't run any expressions. Objective C
// can run an expression to determine if a SBValue is a dynamic type or not
// and we need to avoid this. OperatingSystem plug-ins can't run expressions
// that require running code...
Target &target = GetTarget();
const lldb::DynamicValueType saved_prefer_dynamic = target.GetPreferDynamicValue ();
if (saved_prefer_dynamic != lldb::eNoDynamicValues)
target.SetPreferDynamicValue(lldb::eNoDynamicValues);
// Now let the OperatingSystem plug-in update the thread list
os->UpdateThreadList (old_thread_list, // Old list full of threads created by OS plug-in
real_thread_list, // The actual thread list full of threads created by each lldb_private::Process subclass
new_thread_list); // The new thread list that we will show to the user that gets filled in
if (saved_prefer_dynamic != lldb::eNoDynamicValues)
target.SetPreferDynamicValue(saved_prefer_dynamic);
}
else
{
// No OS plug-in, the new thread list is the same as the real thread list
new_thread_list = real_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
}
Remember to update the m_thread_list_real after you do UpdateThreadList. <rdar://problem/14147303> llvm-svn: 184622
2013-06-22 08:55:02 +08:00
m_thread_list_real.Update(real_thread_list);
Reinstating r181091 and r181106 with fix for Linux regressions. llvm-svn: 181340
2013-05-08 02:35:34 +08:00
m_thread_list.Update (new_thread_list);
m_thread_list.SetStopID (stop_id);
Add logging for the SB API which creates extended threads. Take a stab at fixing the too-soon freeing of the extended backtrace thread list in Process. <rdar://problem/15496603> llvm-svn: 195104
2013-11-19 13:44:41 +08:00
Flush the Process' cache of extended threads every time the natural stop id is updated. <rdar://problem/15496603> llvm-svn: 195177
2013-11-20 08:31:38 +08:00
if (GetLastNaturalStopID () != m_extended_thread_stop_id)
{
// Clear any extended threads that we may have accumulated previously
m_extended_thread_list.Clear();
m_extended_thread_stop_id = GetLastNaturalStopID ();
Add new Queue, QueueItem, Queuelist, SBQueue, SBQueueItem classes to represent libdispatch aka Grand Central Dispatch (GCD) queues. Still fleshing out the documentation and testing of these but the overall API is settling down so it's a good time to check it in. <rdar://problem/15600370> llvm-svn: 197190
2013-12-13 08:29:16 +08:00
m_queue_list.Clear();
m_queue_list_stop_id = GetLastNaturalStopID ();
Flush the Process' cache of extended threads every time the natural stop id is updated. <rdar://problem/15496603> llvm-svn: 195177
2013-11-20 08:31:38 +08:00
}
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
}
}
Add new Queue, QueueItem, Queuelist, SBQueue, SBQueueItem classes to represent libdispatch aka Grand Central Dispatch (GCD) queues. Still fleshing out the documentation and testing of these but the overall API is settling down so it's a good time to check it in. <rdar://problem/15600370> llvm-svn: 197190
2013-12-13 08:29:16 +08:00
void
Process::UpdateQueueListIfNeeded ()
{
if (m_system_runtime_ap.get())
{
if (m_queue_list.GetSize() == 0 || m_queue_list_stop_id != GetLastNaturalStopID())
{
const StateType state = GetPrivateState();
if (StateIsStoppedState (state, true))
{
m_system_runtime_ap->PopulateQueueList (m_queue_list);
m_queue_list_stop_id = GetLastNaturalStopID();
}
}
}
}
<rdar://problem/13010007> Added the ability for OS plug-ins to lazily populate the thread this. The python OS plug-in classes can now implement the following method: class OperatingSystemPlugin: def create_thread(self, tid, context): # Return a dictionary for a new thread to create it on demand This will add a new thread to the thread list if it doesn't already exist. The example code in lldb/examples/python/operating_system.py has been updated to show how this call us used. Cleaned up the code in PythonDataObjects.cpp/h: - renamed all classes that started with PythonData* to be Python*. - renamed PythonArray to PythonList. Cleaned up the code to use inheritance where - Centralized the code that does ref counting in the PythonObject class to a single function. - Made the "bool PythonObject::Reset(PyObject *)" function be virtual so each subclass can correctly check to ensure a PyObject is of the right type before adopting the object. - Cleaned up all APIs and added new constructors for the Python* classes to they can all construct form: - PyObject * - const PythonObject & - const lldb::ScriptInterpreterObjectSP & Cleaned up code in ScriptInterpreterPython: - Made calling python functions safer by templatizing the production of value formats. Python specifies the value formats based on built in C types (long, long long, etc), and code often uses typedefs for uint32_t, uint64_t, etc when passing arguments down to python. We will now always produce correct value formats as the templatized code will "do the right thing" all the time. - Fixed issues with the ScriptInterpreterPython::Locker where entering the session and leaving the session had a bunch of issues that could cause the "lldb" module globals lldb.debugger, lldb.target, lldb.process, lldb.thread, and lldb.frame to not be initialized. llvm-svn: 172873
2013-01-19 07:41:08 +08:00
ThreadSP
Process::CreateOSPluginThread (lldb::tid_t tid, lldb::addr_t context)
{
OperatingSystem *os = GetOperatingSystem ();
if (os)
return os->CreateThread(tid, context);
return ThreadSP();
}
<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)
{
Fix Clang-tidy modernize-use-override warnings in source/Target; other minor fixes. llvm-svn: 251134
2015-10-24 02:39:37 +08:00
return (m_thread_id_to_index_id_map.find(thread_id) != m_thread_id_to_index_id_map.end());
<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::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 ();
}
Make the "synchronous" mode actually work without race conditions. There were many issues with synchronous mode that we discovered when started to try and add a "batch" mode. There was a race condition where the event handling thread might consume events when in sync mode and other times the Process::WaitForProcessToStop() would consume them. This also led to places where the Process IO handler might or might not get popped when it needed to be. llvm-svn: 220254
2014-10-21 09:00:42 +08:00
bool
Process::StateChangedIsExternallyHijacked()
{
if (IsHijackedForEvent(eBroadcastBitStateChanged))
{
if (strcmp(m_hijacking_listeners.back()->GetName(), "lldb.Process.ResumeSynchronous.hijack"))
return true;
}
return false;
}
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
void
Figure out the reply to "PlanExplainsStop" once when we stop and then use the cached value. This fixes problems, for instance, with the StepRange plans, where they know that they explained the stop because they were at their "run to here" breakpoint, then deleted that breakpoint, so when they got asked again, doh! I had done this for a couple of plans in an ad hoc fashion, this just formalizes it. Also add a "ResumeRequested" in Process so that the code in the completion handlers can tell the ShouldStop logic they want to resume rather than just directly resuming. That allows us to handle resuming in a more controlled fashion. Also, SetPublicState can take a "restarted" flag, so that it doesn't drop the run lock when the target was immediately restarted. --This line, and those below , will be ignored-- M test/lang/objc/objc-dynamic-value/TestObjCDynamicValue.py M include/lldb/Target/ThreadList.h M include/lldb/Target/ThreadPlanStepOut.h M include/lldb/Target/Thread.h M include/lldb/Target/ThreadPlanBase.h M include/lldb/Target/ThreadPlanStepThrough.h M include/lldb/Target/ThreadPlanStepInstruction.h M include/lldb/Target/ThreadPlanStepInRange.h M include/lldb/Target/ThreadPlanStepOverBreakpoint.h M include/lldb/Target/ThreadPlanStepUntil.h M include/lldb/Target/StopInfo.h M include/lldb/Target/Process.h M include/lldb/Target/ThreadPlanRunToAddress.h M include/lldb/Target/ThreadPlan.h M include/lldb/Target/ThreadPlanCallFunction.h M include/lldb/Target/ThreadPlanStepOverRange.h M source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleThreadPlanStepThroughObjCTrampoline.h M source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleThreadPlanStepThroughObjCTrampoline.cpp M source/Target/StopInfo.cpp M source/Target/Process.cpp M source/Target/ThreadPlanRunToAddress.cpp M source/Target/ThreadPlan.cpp M source/Target/ThreadPlanCallFunction.cpp M source/Target/ThreadPlanStepOverRange.cpp M source/Target/ThreadList.cpp M source/Target/ThreadPlanStepOut.cpp M source/Target/Thread.cpp M source/Target/ThreadPlanBase.cpp M source/Target/ThreadPlanStepThrough.cpp M source/Target/ThreadPlanStepInstruction.cpp M source/Target/ThreadPlanStepInRange.cpp M source/Target/ThreadPlanStepOverBreakpoint.cpp M source/Target/ThreadPlanStepUntil.cpp M lldb.xcodeproj/xcshareddata/xcschemes/Run Testsuite.xcscheme llvm-svn: 181381
2013-05-08 08:35:16 +08:00
Process::SetPublicState (StateType new_state, bool restarted)
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_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)
Figure out the reply to "PlanExplainsStop" once when we stop and then use the cached value. This fixes problems, for instance, with the StepRange plans, where they know that they explained the stop because they were at their "run to here" breakpoint, then deleted that breakpoint, so when they got asked again, doh! I had done this for a couple of plans in an ad hoc fashion, this just formalizes it. Also add a "ResumeRequested" in Process so that the code in the completion handlers can tell the ShouldStop logic they want to resume rather than just directly resuming. That allows us to handle resuming in a more controlled fashion. Also, SetPublicState can take a "restarted" flag, so that it doesn't drop the run lock when the target was immediately restarted. --This line, and those below , will be ignored-- M test/lang/objc/objc-dynamic-value/TestObjCDynamicValue.py M include/lldb/Target/ThreadList.h M include/lldb/Target/ThreadPlanStepOut.h M include/lldb/Target/Thread.h M include/lldb/Target/ThreadPlanBase.h M include/lldb/Target/ThreadPlanStepThrough.h M include/lldb/Target/ThreadPlanStepInstruction.h M include/lldb/Target/ThreadPlanStepInRange.h M include/lldb/Target/ThreadPlanStepOverBreakpoint.h M include/lldb/Target/ThreadPlanStepUntil.h M include/lldb/Target/StopInfo.h M include/lldb/Target/Process.h M include/lldb/Target/ThreadPlanRunToAddress.h M include/lldb/Target/ThreadPlan.h M include/lldb/Target/ThreadPlanCallFunction.h M include/lldb/Target/ThreadPlanStepOverRange.h M source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleThreadPlanStepThroughObjCTrampoline.h M source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleThreadPlanStepThroughObjCTrampoline.cpp M source/Target/StopInfo.cpp M source/Target/Process.cpp M source/Target/ThreadPlanRunToAddress.cpp M source/Target/ThreadPlan.cpp M source/Target/ThreadPlanCallFunction.cpp M source/Target/ThreadPlanStepOverRange.cpp M source/Target/ThreadList.cpp M source/Target/ThreadPlanStepOut.cpp M source/Target/Thread.cpp M source/Target/ThreadPlanBase.cpp M source/Target/ThreadPlanStepThrough.cpp M source/Target/ThreadPlanStepInstruction.cpp M source/Target/ThreadPlanStepInRange.cpp M source/Target/ThreadPlanStepOverBreakpoint.cpp M source/Target/ThreadPlanStepUntil.cpp M lldb.xcodeproj/xcshareddata/xcschemes/Run Testsuite.xcscheme llvm-svn: 181381
2013-05-08 08:35:16 +08:00
log->Printf("Process::SetPublicState (state = %s, restarted = %i)", StateAsCString(new_state), restarted);
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.
Make the "synchronous" mode actually work without race conditions. There were many issues with synchronous mode that we discovered when started to try and add a "batch" mode. There was a race condition where the event handling thread might consume events when in sync mode and other times the Process::WaitForProcessToStop() would consume them. This also led to places where the Process IO handler might or might not get popped when it needed to be. llvm-svn: 220254
2014-10-21 09:00:42 +08:00
if (!StateChangedIsExternallyHijacked())
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 == 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));
Use flag instead of rwlock state to track process running state LLDB requires that the inferior process be stopped before, and remain stopped during, certain accesses to process state. Previously this was achieved with a POSIX rwlock which had a write lock taken for the duration that the process was running, and released when the process was stopped. Any access to process state was performed with a read lock held. However, POSIX requires that pthread_rwlock_unlock() be called from the same thread as pthread_rwlock_wrlock(), and lldb needs to stop and start the process from different threads. Violating this constraint is technically undefined behaviour, although as it happens Linux and Darwin result in the unlock proceeding in this case. FreeBSD follows POSIX more strictly, and the unlock would fail, resulting in a hang later upon the next attempt to take the lock. All read lock consumers use ReadTryLock() and handle failure to obtain the lock (typically by logging an error "process is running"). Thus, instead of using the lock state itself to track the running state, this change adds an explicit m_running flag. ReadTryLock tests the flag, and if the process is not running it returns with the read lock held. WriteLock and WriteTryLock are renamed to SetRunning and TrySetRunning, and (if successful) they set m_running with the lock held. This way, read consumers can determine if the process is running and act appropriately, and write consumers are still held off from starting the process if read consumers are active. Note that with this change there are still some curious access patterns, such as calling WriteUnlock / SetStopped twice in a row, and there's no protection from multiple threads trying to simultaneously start the process. In practice this does not seem to be a problem, and was exposing other undefined POSIX behaviour prior to this change. llvm-svn: 187377
2013-07-30 04:58:06 +08:00
m_public_run_lock.SetStopped();
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
}
else
{
const bool old_state_is_stopped = StateIsStoppedState(old_state, false);
const bool new_state_is_stopped = StateIsStoppedState(new_state, false);
Figure out the reply to "PlanExplainsStop" once when we stop and then use the cached value. This fixes problems, for instance, with the StepRange plans, where they know that they explained the stop because they were at their "run to here" breakpoint, then deleted that breakpoint, so when they got asked again, doh! I had done this for a couple of plans in an ad hoc fashion, this just formalizes it. Also add a "ResumeRequested" in Process so that the code in the completion handlers can tell the ShouldStop logic they want to resume rather than just directly resuming. That allows us to handle resuming in a more controlled fashion. Also, SetPublicState can take a "restarted" flag, so that it doesn't drop the run lock when the target was immediately restarted. --This line, and those below , will be ignored-- M test/lang/objc/objc-dynamic-value/TestObjCDynamicValue.py M include/lldb/Target/ThreadList.h M include/lldb/Target/ThreadPlanStepOut.h M include/lldb/Target/Thread.h M include/lldb/Target/ThreadPlanBase.h M include/lldb/Target/ThreadPlanStepThrough.h M include/lldb/Target/ThreadPlanStepInstruction.h M include/lldb/Target/ThreadPlanStepInRange.h M include/lldb/Target/ThreadPlanStepOverBreakpoint.h M include/lldb/Target/ThreadPlanStepUntil.h M include/lldb/Target/StopInfo.h M include/lldb/Target/Process.h M include/lldb/Target/ThreadPlanRunToAddress.h M include/lldb/Target/ThreadPlan.h M include/lldb/Target/ThreadPlanCallFunction.h M include/lldb/Target/ThreadPlanStepOverRange.h M source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleThreadPlanStepThroughObjCTrampoline.h M source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleThreadPlanStepThroughObjCTrampoline.cpp M source/Target/StopInfo.cpp M source/Target/Process.cpp M source/Target/ThreadPlanRunToAddress.cpp M source/Target/ThreadPlan.cpp M source/Target/ThreadPlanCallFunction.cpp M source/Target/ThreadPlanStepOverRange.cpp M source/Target/ThreadList.cpp M source/Target/ThreadPlanStepOut.cpp M source/Target/Thread.cpp M source/Target/ThreadPlanBase.cpp M source/Target/ThreadPlanStepThrough.cpp M source/Target/ThreadPlanStepInstruction.cpp M source/Target/ThreadPlanStepInRange.cpp M source/Target/ThreadPlanStepOverBreakpoint.cpp M source/Target/ThreadPlanStepUntil.cpp M lldb.xcodeproj/xcshareddata/xcschemes/Run Testsuite.xcscheme llvm-svn: 181381
2013-05-08 08:35:16 +08:00
if ((old_state_is_stopped != new_state_is_stopped))
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
{
Figure out the reply to "PlanExplainsStop" once when we stop and then use the cached value. This fixes problems, for instance, with the StepRange plans, where they know that they explained the stop because they were at their "run to here" breakpoint, then deleted that breakpoint, so when they got asked again, doh! I had done this for a couple of plans in an ad hoc fashion, this just formalizes it. Also add a "ResumeRequested" in Process so that the code in the completion handlers can tell the ShouldStop logic they want to resume rather than just directly resuming. That allows us to handle resuming in a more controlled fashion. Also, SetPublicState can take a "restarted" flag, so that it doesn't drop the run lock when the target was immediately restarted. --This line, and those below , will be ignored-- M test/lang/objc/objc-dynamic-value/TestObjCDynamicValue.py M include/lldb/Target/ThreadList.h M include/lldb/Target/ThreadPlanStepOut.h M include/lldb/Target/Thread.h M include/lldb/Target/ThreadPlanBase.h M include/lldb/Target/ThreadPlanStepThrough.h M include/lldb/Target/ThreadPlanStepInstruction.h M include/lldb/Target/ThreadPlanStepInRange.h M include/lldb/Target/ThreadPlanStepOverBreakpoint.h M include/lldb/Target/ThreadPlanStepUntil.h M include/lldb/Target/StopInfo.h M include/lldb/Target/Process.h M include/lldb/Target/ThreadPlanRunToAddress.h M include/lldb/Target/ThreadPlan.h M include/lldb/Target/ThreadPlanCallFunction.h M include/lldb/Target/ThreadPlanStepOverRange.h M source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleThreadPlanStepThroughObjCTrampoline.h M source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleThreadPlanStepThroughObjCTrampoline.cpp M source/Target/StopInfo.cpp M source/Target/Process.cpp M source/Target/ThreadPlanRunToAddress.cpp M source/Target/ThreadPlan.cpp M source/Target/ThreadPlanCallFunction.cpp M source/Target/ThreadPlanStepOverRange.cpp M source/Target/ThreadList.cpp M source/Target/ThreadPlanStepOut.cpp M source/Target/Thread.cpp M source/Target/ThreadPlanBase.cpp M source/Target/ThreadPlanStepThrough.cpp M source/Target/ThreadPlanStepInstruction.cpp M source/Target/ThreadPlanStepInRange.cpp M source/Target/ThreadPlanStepOverBreakpoint.cpp M source/Target/ThreadPlanStepUntil.cpp M lldb.xcodeproj/xcshareddata/xcschemes/Run Testsuite.xcscheme llvm-svn: 181381
2013-05-08 08:35:16 +08:00
if (new_state_is_stopped && !restarted)
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", StateAsCString(new_state));
Use flag instead of rwlock state to track process running state LLDB requires that the inferior process be stopped before, and remain stopped during, certain accesses to process state. Previously this was achieved with a POSIX rwlock which had a write lock taken for the duration that the process was running, and released when the process was stopped. Any access to process state was performed with a read lock held. However, POSIX requires that pthread_rwlock_unlock() be called from the same thread as pthread_rwlock_wrlock(), and lldb needs to stop and start the process from different threads. Violating this constraint is technically undefined behaviour, although as it happens Linux and Darwin result in the unlock proceeding in this case. FreeBSD follows POSIX more strictly, and the unlock would fail, resulting in a hang later upon the next attempt to take the lock. All read lock consumers use ReadTryLock() and handle failure to obtain the lock (typically by logging an error "process is running"). Thus, instead of using the lock state itself to track the running state, this change adds an explicit m_running flag. ReadTryLock tests the flag, and if the process is not running it returns with the read lock held. WriteLock and WriteTryLock are renamed to SetRunning and TrySetRunning, and (if successful) they set m_running with the lock held. This way, read consumers can determine if the process is running and act appropriately, and write consumers are still held off from starting the process if read consumers are active. Note that with this change there are still some curious access patterns, such as calling WriteUnlock / SetStopped twice in a row, and there's no protection from multiple threads trying to simultaneously start the process. In practice this does not seem to be a problem, and was exposing other undefined POSIX behaviour prior to this change. llvm-svn: 187377
2013-07-30 04:58:06 +08:00
m_public_run_lock.SetStopped();
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
}
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");
Use flag instead of rwlock state to track process running state LLDB requires that the inferior process be stopped before, and remain stopped during, certain accesses to process state. Previously this was achieved with a POSIX rwlock which had a write lock taken for the duration that the process was running, and released when the process was stopped. Any access to process state was performed with a read lock held. However, POSIX requires that pthread_rwlock_unlock() be called from the same thread as pthread_rwlock_wrlock(), and lldb needs to stop and start the process from different threads. Violating this constraint is technically undefined behaviour, although as it happens Linux and Darwin result in the unlock proceeding in this case. FreeBSD follows POSIX more strictly, and the unlock would fail, resulting in a hang later upon the next attempt to take the lock. All read lock consumers use ReadTryLock() and handle failure to obtain the lock (typically by logging an error "process is running"). Thus, instead of using the lock state itself to track the running state, this change adds an explicit m_running flag. ReadTryLock tests the flag, and if the process is not running it returns with the read lock held. WriteLock and WriteTryLock are renamed to SetRunning and TrySetRunning, and (if successful) they set m_running with the lock held. This way, read consumers can determine if the process is running and act appropriately, and write consumers are still held off from starting the process if read consumers are active. Note that with this change there are still some curious access patterns, such as calling WriteUnlock / SetStopped twice in a row, and there's no protection from multiple threads trying to simultaneously start the process. In practice this does not seem to be a problem, and was exposing other undefined POSIX behaviour prior to this change. llvm-svn: 187377
2013-07-30 04:58:06 +08:00
if (!m_public_run_lock.TrySetRunning())
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 error("Resume request failed - process still running.");
if (log)
Use flag instead of rwlock state to track process running state LLDB requires that the inferior process be stopped before, and remain stopped during, certain accesses to process state. Previously this was achieved with a POSIX rwlock which had a write lock taken for the duration that the process was running, and released when the process was stopped. Any access to process state was performed with a read lock held. However, POSIX requires that pthread_rwlock_unlock() be called from the same thread as pthread_rwlock_wrlock(), and lldb needs to stop and start the process from different threads. Violating this constraint is technically undefined behaviour, although as it happens Linux and Darwin result in the unlock proceeding in this case. FreeBSD follows POSIX more strictly, and the unlock would fail, resulting in a hang later upon the next attempt to take the lock. All read lock consumers use ReadTryLock() and handle failure to obtain the lock (typically by logging an error "process is running"). Thus, instead of using the lock state itself to track the running state, this change adds an explicit m_running flag. ReadTryLock tests the flag, and if the process is not running it returns with the read lock held. WriteLock and WriteTryLock are renamed to SetRunning and TrySetRunning, and (if successful) they set m_running with the lock held. This way, read consumers can determine if the process is running and act appropriately, and write consumers are still held off from starting the process if read consumers are active. Note that with this change there are still some curious access patterns, such as calling WriteUnlock / SetStopped twice in a row, and there's no protection from multiple threads trying to simultaneously start the process. In practice this does not seem to be a problem, and was exposing other undefined POSIX behaviour prior to this change. llvm-svn: 187377
2013-07-30 04:58:06 +08:00
log->Printf ("Process::Resume: -- TrySetRunning failed, not resuming.");
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
return error;
}
return PrivateResume();
}
Make the "synchronous" mode actually work without race conditions. There were many issues with synchronous mode that we discovered when started to try and add a "batch" mode. There was a race condition where the event handling thread might consume events when in sync mode and other times the Process::WaitForProcessToStop() would consume them. This also led to places where the Process IO handler might or might not get popped when it needed to be. llvm-svn: 220254
2014-10-21 09:00:42 +08:00
Error
Process::ResumeSynchronous (Stream *stream)
{
Log *log(lldb_private::GetLogIfAnyCategoriesSet (LIBLLDB_LOG_STATE | LIBLLDB_LOG_PROCESS));
if (log)
log->Printf("Process::ResumeSynchronous -- locking run lock");
if (!m_public_run_lock.TrySetRunning())
{
Error error("Resume request failed - process still running.");
if (log)
log->Printf ("Process::Resume: -- TrySetRunning failed, not resuming.");
return error;
}
ListenerSP listener_sp (new Listener("lldb.Process.ResumeSynchronous.hijack"));
HijackProcessEvents(listener_sp.get());
Error error = PrivateResume();
Fix Process::ResumeSynchronous which waits a process even in case of error llvm-svn: 236231
2015-04-30 21:10:32 +08:00
if (error.Success())
{
StateType state = WaitForProcessToStop (NULL, NULL, true, listener_sp.get(), stream);
const bool must_be_alive = false; // eStateExited is ok, so this must be false
if (!StateIsStoppedState(state, must_be_alive))
error.SetErrorStringWithFormat("process not in stopped state after synchronous resume: %s", StateAsCString(state));
}
Make the "synchronous" mode actually work without race conditions. There were many issues with synchronous mode that we discovered when started to try and add a "batch" mode. There was a race condition where the event handling thread might consume events when in sync mode and other times the Process::WaitForProcessToStop() would consume them. This also led to places where the Process IO handler might or might not get popped when it needed to be. llvm-svn: 220254
2014-10-21 09:00:42 +08:00
// Undo the hijacking of process events...
RestoreProcessEvents();
return error;
}
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)
{
If Process::Finalize() has been called, don't track process state changes. <rdar://problem/17540766> llvm-svn: 213007
2014-07-15 07:09:29 +08:00
if (m_finalize_called)
return;
<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));
Adding support for setting thread stop state when a process stops. This re-submission of this patch fixes a problem where the code sometimes caused a deadlock. The Process::SetPrivateState method was locking the Process::m_private_state variable and then later calling ThreadList::DidStop, which locks the ThreadList mutex. Other methods in ThreadList which were being called from other threads lock the ThreadList mutex and then call Process::GetPrivateState which locks the Process::m_private_state mutex. To avoid deadlocks, Process::SetPrivateState now locks the ThreadList mutex before locking the Process::m_private_state mutex. llvm-svn: 181609
2013-05-11 01:19:04 +08:00
Mutex::Locker thread_locker(m_thread_list.GetMutex());
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
Mutex::Locker locker(m_private_state.GetMutex());
const StateType old_state = m_private_state.GetValueNoLock ();
state_changed = old_state != new_state;
Remove obsolete comment llvm-svn: 185441
2013-07-03 00:35:47 +08:00
Clear up any deadlocks on Apple builds that were due to the lldb_private::Process.m_private_run_lock variable. If someone on Linux and/or FreeBSD can try to comment out the " #if defined(__APPLE__)" that surrounds access to "m_private_run_lock" and run the test suite, that would be nice. The new location where the locking/unlocking happens is bulletproof on MacOSX, and I want to verify that it is good on linux as well. llvm-svn: 181061
2013-05-04 06:25:56 +08:00
const bool old_state_is_stopped = StateIsStoppedState(old_state, false);
const bool new_state_is_stopped = StateIsStoppedState(new_state, false);
if (old_state_is_stopped != new_state_is_stopped)
{
if (new_state_is_stopped)
Use flag instead of rwlock state to track process running state LLDB requires that the inferior process be stopped before, and remain stopped during, certain accesses to process state. Previously this was achieved with a POSIX rwlock which had a write lock taken for the duration that the process was running, and released when the process was stopped. Any access to process state was performed with a read lock held. However, POSIX requires that pthread_rwlock_unlock() be called from the same thread as pthread_rwlock_wrlock(), and lldb needs to stop and start the process from different threads. Violating this constraint is technically undefined behaviour, although as it happens Linux and Darwin result in the unlock proceeding in this case. FreeBSD follows POSIX more strictly, and the unlock would fail, resulting in a hang later upon the next attempt to take the lock. All read lock consumers use ReadTryLock() and handle failure to obtain the lock (typically by logging an error "process is running"). Thus, instead of using the lock state itself to track the running state, this change adds an explicit m_running flag. ReadTryLock tests the flag, and if the process is not running it returns with the read lock held. WriteLock and WriteTryLock are renamed to SetRunning and TrySetRunning, and (if successful) they set m_running with the lock held. This way, read consumers can determine if the process is running and act appropriately, and write consumers are still held off from starting the process if read consumers are active. Note that with this change there are still some curious access patterns, such as calling WriteUnlock / SetStopped twice in a row, and there's no protection from multiple threads trying to simultaneously start the process. In practice this does not seem to be a problem, and was exposing other undefined POSIX behaviour prior to this change. llvm-svn: 187377
2013-07-30 04:58:06 +08:00
m_private_run_lock.SetStopped();
Clear up any deadlocks on Apple builds that were due to the lldb_private::Process.m_private_run_lock variable. If someone on Linux and/or FreeBSD can try to comment out the " #if defined(__APPLE__)" that surrounds access to "m_private_run_lock" and run the test suite, that would be nice. The new location where the locking/unlocking happens is bulletproof on MacOSX, and I want to verify that it is good on linux as well. llvm-svn: 181061
2013-05-04 06:25:56 +08:00
else
Use flag instead of rwlock state to track process running state LLDB requires that the inferior process be stopped before, and remain stopped during, certain accesses to process state. Previously this was achieved with a POSIX rwlock which had a write lock taken for the duration that the process was running, and released when the process was stopped. Any access to process state was performed with a read lock held. However, POSIX requires that pthread_rwlock_unlock() be called from the same thread as pthread_rwlock_wrlock(), and lldb needs to stop and start the process from different threads. Violating this constraint is technically undefined behaviour, although as it happens Linux and Darwin result in the unlock proceeding in this case. FreeBSD follows POSIX more strictly, and the unlock would fail, resulting in a hang later upon the next attempt to take the lock. All read lock consumers use ReadTryLock() and handle failure to obtain the lock (typically by logging an error "process is running"). Thus, instead of using the lock state itself to track the running state, this change adds an explicit m_running flag. ReadTryLock tests the flag, and if the process is not running it returns with the read lock held. WriteLock and WriteTryLock are renamed to SetRunning and TrySetRunning, and (if successful) they set m_running with the lock held. This way, read consumers can determine if the process is running and act appropriately, and write consumers are still held off from starting the process if read consumers are active. Note that with this change there are still some curious access patterns, such as calling WriteUnlock / SetStopped twice in a row, and there's no protection from multiple threads trying to simultaneously start the process. In practice this does not seem to be a problem, and was exposing other undefined POSIX behaviour prior to this change. llvm-svn: 187377
2013-07-30 04:58:06 +08:00
m_private_run_lock.SetRunning();
Clear up any deadlocks on Apple builds that were due to the lldb_private::Process.m_private_run_lock variable. If someone on Linux and/or FreeBSD can try to comment out the " #if defined(__APPLE__)" that surrounds access to "m_private_run_lock" and run the test suite, that would be nice. The new location where the locking/unlocking happens is bulletproof on MacOSX, and I want to verify that it is good on linux as well. llvm-svn: 181061
2013-05-04 06:25:56 +08:00
}
Adding support for stopping all threads of multithreaded inferiors on Linux. Also adding multithreaded test cases. llvm-svn: 182809
2013-05-29 07:04:25 +08:00
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);
Fix handling of hijacked events in synchronous mode Summary: This patch includes the following changes: * Fix Target::Launch to handle hijacked event in synchronous mode * Improve MiStartupOptionsTestCase tests to expect *stopped (MI) * Add SBProcess::GetStopEventForStopID * Add ProcessModID::SetStopEventForLastNaturalStopID/GetStopEventForStopID * Add const qualifier to ProcessModID::GetLastNaturalStopID * Add SBProcess::GetStopEventForStopID * Don't broadcast hijacked event in Target::Launch * Add CMICmnLLDBDebugger::CheckIfNeedToRebroadcastStopEvent/RebroadcastStopEvent Test Plan: ./dotest.py -v --executable $BUILDDIR/bin/lldb tools/lldb-mi/startup_options/ Reviewers: zturner, jingham, clayborg, abidh Reviewed By: clayborg Subscribers: abidh, zturner, lldb-commits, clayborg, jingham Differential Revision: http://reviews.llvm.org/D9371 llvm-svn: 237781
2015-05-20 18:15:47 +08:00
EventSP event_sp (new Event (eBroadcastBitStateChanged, new ProcessEventData (shared_from_this(), 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
{
Adding support for setting thread stop state when a process stops. This re-submission of this patch fixes a problem where the code sometimes caused a deadlock. The Process::SetPrivateState method was locking the Process::m_private_state variable and then later calling ThreadList::DidStop, which locks the ThreadList mutex. Other methods in ThreadList which were being called from other threads lock the ThreadList mutex and then call Process::GetPrivateState which locks the Process::m_private_state mutex. To avoid deadlocks, Process::SetPrivateState now locks the ThreadList mutex before locking the Process::m_private_state mutex. llvm-svn: 181609
2013-05-11 01:19:04 +08:00
// Note, this currently assumes that all threads in the list
// stop when the process stops. In the future we will want to
// support a debugging model where some threads continue to run
// while others are stopped. When that happens we will either need
// a way for the thread list to identify which threads are stopping
// or create a special thread list containing only threads which
// actually stopped.
//
// The process plugin is responsible for managing the actual
// behavior of the threads and should have stopped any threads
// that are going to stop before we get here.
m_thread_list.DidStop();
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();
Fix handling of hijacked events in synchronous mode Summary: This patch includes the following changes: * Fix Target::Launch to handle hijacked event in synchronous mode * Improve MiStartupOptionsTestCase tests to expect *stopped (MI) * Add SBProcess::GetStopEventForStopID * Add ProcessModID::SetStopEventForLastNaturalStopID/GetStopEventForStopID * Add const qualifier to ProcessModID::GetLastNaturalStopID * Add SBProcess::GetStopEventForStopID * Don't broadcast hijacked event in Target::Launch * Add CMICmnLLDBDebugger::CheckIfNeedToRebroadcastStopEvent/RebroadcastStopEvent Test Plan: ./dotest.py -v --executable $BUILDDIR/bin/lldb tools/lldb-mi/startup_options/ Reviewers: zturner, jingham, clayborg, abidh Reviewed By: clayborg Subscribers: abidh, zturner, lldb-commits, clayborg, jingham Differential Revision: http://reviews.llvm.org/D9371 llvm-svn: 237781
2015-05-20 18:15:47 +08:00
if (!m_mod_id.IsLastResumeForUserExpression())
m_mod_id.SetStopEventForLastNaturalStopID(event_sp);
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
}
Fix handling of hijacked events in synchronous mode Summary: This patch includes the following changes: * Fix Target::Launch to handle hijacked event in synchronous mode * Improve MiStartupOptionsTestCase tests to expect *stopped (MI) * Add SBProcess::GetStopEventForStopID * Add ProcessModID::SetStopEventForLastNaturalStopID/GetStopEventForStopID * Add const qualifier to ProcessModID::GetLastNaturalStopID * Add SBProcess::GetStopEventForStopID * Don't broadcast hijacked event in Target::Launch * Add CMICmnLLDBDebugger::CheckIfNeedToRebroadcastStopEvent/RebroadcastStopEvent Test Plan: ./dotest.py -v --executable $BUILDDIR/bin/lldb tools/lldb-mi/startup_options/ Reviewers: zturner, jingham, clayborg, abidh Reviewed By: clayborg Subscribers: abidh, zturner, lldb-commits, clayborg, jingham Differential Revision: http://reviews.llvm.org/D9371 llvm-svn: 237781
2015-05-20 18:15:47 +08:00
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)
Fix handling of hijacked events in synchronous mode Summary: This patch includes the following changes: * Fix Target::Launch to handle hijacked event in synchronous mode * Improve MiStartupOptionsTestCase tests to expect *stopped (MI) * Add SBProcess::GetStopEventForStopID * Add ProcessModID::SetStopEventForLastNaturalStopID/GetStopEventForStopID * Add const qualifier to ProcessModID::GetLastNaturalStopID * Add SBProcess::GetStopEventForStopID * Don't broadcast hijacked event in Target::Launch * Add CMICmnLLDBDebugger::CheckIfNeedToRebroadcastStopEvent/RebroadcastStopEvent Test Plan: ./dotest.py -v --executable $BUILDDIR/bin/lldb tools/lldb-mi/startup_options/ Reviewers: zturner, jingham, clayborg, abidh Reviewed By: clayborg Subscribers: abidh, zturner, lldb-commits, clayborg, jingham Differential Revision: http://reviews.llvm.org/D9371 llvm-svn: 237781
2015-05-20 18:15:47 +08:00
BroadcastEvent (event_sp);
<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
else
Fix handling of hijacked events in synchronous mode Summary: This patch includes the following changes: * Fix Target::Launch to handle hijacked event in synchronous mode * Improve MiStartupOptionsTestCase tests to expect *stopped (MI) * Add SBProcess::GetStopEventForStopID * Add ProcessModID::SetStopEventForLastNaturalStopID/GetStopEventForStopID * Add const qualifier to ProcessModID::GetLastNaturalStopID * Add SBProcess::GetStopEventForStopID * Don't broadcast hijacked event in Target::Launch * Add CMICmnLLDBDebugger::CheckIfNeedToRebroadcastStopEvent/RebroadcastStopEvent Test Plan: ./dotest.py -v --executable $BUILDDIR/bin/lldb tools/lldb-mi/startup_options/ Reviewers: zturner, jingham, clayborg, abidh Reviewed By: clayborg Subscribers: abidh, zturner, lldb-commits, clayborg, jingham Differential Revision: http://reviews.llvm.org/D9371 llvm-svn: 237781
2015-05-20 18:15:47 +08:00
m_private_state_broadcaster.BroadcastEvent (event_sp);
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;
}
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)
Have the Process hold a weak_ptr to the Target. llvm-svn: 246578
2015-09-02 04:02:29 +08:00
m_abi_sp = ABI::FindPlugin(GetTarget().GetArchitecture());
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
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
{
Fix a crasher that could happen when you run LLDB and evaluate an expression where the objective C runtime registers a helper function, and also have an Objective C or C++ exception breakpoint. When shutting down the process in Process::Finalize() we clear a STL collection class and that causes objects to be destroyed that could re-enter Process and cause it to try to iterate over that same collection class that is being destroyed. Guard against this by setting a new "m_finalizing" flag that lets us know we are in the process of finalizing. <rdar://problem/20369152> llvm-svn: 233935
2015-04-03 02:44:58 +08:00
if (m_finalizing)
return nullptr;
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)
{
Fix a crasher that could happen when you run LLDB and evaluate an expression where the objective C runtime registers a helper function, and also have an Objective C or C++ exception breakpoint. When shutting down the process in Process::Finalize() we clear a STL collection class and that causes objects to be destroyed that could re-enter Process and cause it to try to iterate over that same collection class that is being destroyed. Guard against this by setting a new "m_finalizing" flag that lets us know we are in the process of finalizing. <rdar://problem/20369152> llvm-svn: 233935
2015-04-03 02:44:58 +08:00
if (m_finalizing)
return false;
<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
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;
}
Further reduce the header footprint of Process.h No functional change here, only deletes unnecessary headers and moves one function's body from the .h file to the .cpp. llvm-svn: 231145
2015-03-04 05:51:25 +08:00
void
Process::SetDynamicCheckers(DynamicCheckerFunctions *dynamic_checkers)
{
m_dynamic_checkers_ap.reset(dynamic_checkers);
}
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 ()
{
Huge performance improvements when one breakpoint contains many locations. 325,000 breakpoints for running "breakpoint set --func-regex ." on lldb itself (after hitting a breakpoint at main so that LLDB.framework is loaded) used to take up to an hour to set, now we are down under a minute. With warm file caches, we are at 40 seconds, and that is with setting 325,000 breakpoint through the GDB remote API. Linux and the native debuggers might be faster. I haven't timed what how much is debug info parsing and how much is the protocol traffic to/from GDB remote. That there were many performance issues. Most of them were due to storing breakpoints in the wrong data structures, or using the wrong iterators to traverse the lists, traversing the lists in inefficient ways, and not optimizing certain function name lookups/symbol merges correctly. Debugging after that is also now very efficient. There were issues with replacing the breakpoint opcodes in memory that was read, and those routines were also fixed. llvm-svn: 183820
2013-06-12 08:46:38 +08:00
m_breakpoint_site_list.ForEach([this](BreakpointSite *bp_site) -> void {
// bp_site->SetEnabled(true);
DisableBreakpointSite(bp_site);
});
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
{
Get the breakpoint setting, and the Mac OS X DYLD trampolines and expression evaluator to handle Indirect symbols correctly. There were a couple of pieces to this. 1) When a breakpoint location finds itself pointing to an Indirect symbol, when the site for it is created it needs to resolve the symbol and actually set the site at its target. 2) Not all breakpoints want to do this (i.e. a straight address breakpoint should always set itself on the specified address, so somem machinery was needed to specify that. 3) I added some info to the break list output for indirect symbols so you could see what was happening. Also I made it clear when we re-route through re-exported symbols. 4) I moved ResolveIndirectFunction from ProcessPosix to Process since it works the exact same way on Mac OS X and the other posix systems. If we find a platform that doesn't do it this way, they can override the call in Process. 5) Fixed one bug in RunThreadPlan, if you were trying to run a thread plan after a "running" event had been broadcast, the event coalescing would cause you to miss the ThreadPlan running event. So I added a way to override the coalescing. 6) Made DynamicLoaderMacOSXDYLD::GetStepThroughTrampolinePlan handle Indirect & Re-exported symbols. <rdar://problem/15280639> llvm-svn: 198976
2014-01-11 07:46:59 +08:00
addr_t load_addr = LLDB_INVALID_ADDRESS;
bool show_error = true;
switch (GetState())
{
case eStateInvalid:
case eStateUnloaded:
case eStateConnected:
case eStateAttaching:
case eStateLaunching:
case eStateDetached:
case eStateExited:
show_error = false;
break;
case eStateStopped:
case eStateRunning:
case eStateStepping:
case eStateCrashed:
case eStateSuspended:
show_error = IsAlive();
break;
}
// Reset the IsIndirect flag here, in case the location changes from
// pointing to a indirect symbol to a regular symbol.
owner->SetIsIndirect (false);
if (owner->ShouldResolveIndirectFunctions())
{
Symbol *symbol = owner->GetAddress().CalculateSymbolContextSymbol();
if (symbol && symbol->IsIndirect())
{
Error error;
Resubmitting 240466 after fixing the linux test suite failures. A few extras were fixed - Symbol::GetAddress() now returns an Address object, not a reference. There were places where people were accessing the address of a symbol when the symbol's value wasn't an address symbol. On MacOSX, undefined symbols have a value zero and some places where using the symbol's address and getting an absolute address of zero (since an Address object with no section and an m_offset whose value isn't LLDB_INVALID_ADDRESS is considered an absolute address). So fixing this required some changes to make sure people were getting what they expected. - Since some places want to access the address as a reference, I added a few new functions to symbol: Address &Symbol::GetAddressRef(); const Address &Symbol::GetAddressRef() const; Linux test suite passes just fine now. <rdar://problem/21494354> llvm-svn: 240702
2015-06-26 05:46:34 +08:00
Address symbol_address = symbol->GetAddress();
load_addr = ResolveIndirectFunction (&symbol_address, error);
Get the breakpoint setting, and the Mac OS X DYLD trampolines and expression evaluator to handle Indirect symbols correctly. There were a couple of pieces to this. 1) When a breakpoint location finds itself pointing to an Indirect symbol, when the site for it is created it needs to resolve the symbol and actually set the site at its target. 2) Not all breakpoints want to do this (i.e. a straight address breakpoint should always set itself on the specified address, so somem machinery was needed to specify that. 3) I added some info to the break list output for indirect symbols so you could see what was happening. Also I made it clear when we re-route through re-exported symbols. 4) I moved ResolveIndirectFunction from ProcessPosix to Process since it works the exact same way on Mac OS X and the other posix systems. If we find a platform that doesn't do it this way, they can override the call in Process. 5) Fixed one bug in RunThreadPlan, if you were trying to run a thread plan after a "running" event had been broadcast, the event coalescing would cause you to miss the ThreadPlan running event. So I added a way to override the coalescing. 6) Made DynamicLoaderMacOSXDYLD::GetStepThroughTrampolinePlan handle Indirect & Re-exported symbols. <rdar://problem/15280639> llvm-svn: 198976
2014-01-11 07:46:59 +08:00
if (!error.Success() && show_error)
{
Have the Process hold a weak_ptr to the Target. llvm-svn: 246578
2015-09-02 04:02:29 +08:00
GetTarget().GetDebugger().GetErrorFile()->Printf ("warning: failed to resolve indirect function at 0x%" PRIx64 " for breakpoint %i.%i: %s\n",
symbol->GetLoadAddress(&GetTarget()),
owner->GetBreakpoint().GetID(),
owner->GetID(),
error.AsCString() ? error.AsCString() : "unknown error");
Get the breakpoint setting, and the Mac OS X DYLD trampolines and expression evaluator to handle Indirect symbols correctly. There were a couple of pieces to this. 1) When a breakpoint location finds itself pointing to an Indirect symbol, when the site for it is created it needs to resolve the symbol and actually set the site at its target. 2) Not all breakpoints want to do this (i.e. a straight address breakpoint should always set itself on the specified address, so somem machinery was needed to specify that. 3) I added some info to the break list output for indirect symbols so you could see what was happening. Also I made it clear when we re-route through re-exported symbols. 4) I moved ResolveIndirectFunction from ProcessPosix to Process since it works the exact same way on Mac OS X and the other posix systems. If we find a platform that doesn't do it this way, they can override the call in Process. 5) Fixed one bug in RunThreadPlan, if you were trying to run a thread plan after a "running" event had been broadcast, the event coalescing would cause you to miss the ThreadPlan running event. So I added a way to override the coalescing. 6) Made DynamicLoaderMacOSXDYLD::GetStepThroughTrampolinePlan handle Indirect & Re-exported symbols. <rdar://problem/15280639> llvm-svn: 198976
2014-01-11 07:46:59 +08:00
return LLDB_INVALID_BREAK_ID;
}
Address resolved_address(load_addr);
Have the Process hold a weak_ptr to the Target. llvm-svn: 246578
2015-09-02 04:02:29 +08:00
load_addr = resolved_address.GetOpcodeLoadAddress (&GetTarget());
Get the breakpoint setting, and the Mac OS X DYLD trampolines and expression evaluator to handle Indirect symbols correctly. There were a couple of pieces to this. 1) When a breakpoint location finds itself pointing to an Indirect symbol, when the site for it is created it needs to resolve the symbol and actually set the site at its target. 2) Not all breakpoints want to do this (i.e. a straight address breakpoint should always set itself on the specified address, so somem machinery was needed to specify that. 3) I added some info to the break list output for indirect symbols so you could see what was happening. Also I made it clear when we re-route through re-exported symbols. 4) I moved ResolveIndirectFunction from ProcessPosix to Process since it works the exact same way on Mac OS X and the other posix systems. If we find a platform that doesn't do it this way, they can override the call in Process. 5) Fixed one bug in RunThreadPlan, if you were trying to run a thread plan after a "running" event had been broadcast, the event coalescing would cause you to miss the ThreadPlan running event. So I added a way to override the coalescing. 6) Made DynamicLoaderMacOSXDYLD::GetStepThroughTrampolinePlan handle Indirect & Re-exported symbols. <rdar://problem/15280639> llvm-svn: 198976
2014-01-11 07:46:59 +08:00
owner->SetIsIndirect(true);
}
else
Have the Process hold a weak_ptr to the Target. llvm-svn: 246578
2015-09-02 04:02:29 +08:00
load_addr = owner->GetAddress().GetOpcodeLoadAddress (&GetTarget());
Get the breakpoint setting, and the Mac OS X DYLD trampolines and expression evaluator to handle Indirect symbols correctly. There were a couple of pieces to this. 1) When a breakpoint location finds itself pointing to an Indirect symbol, when the site for it is created it needs to resolve the symbol and actually set the site at its target. 2) Not all breakpoints want to do this (i.e. a straight address breakpoint should always set itself on the specified address, so somem machinery was needed to specify that. 3) I added some info to the break list output for indirect symbols so you could see what was happening. Also I made it clear when we re-route through re-exported symbols. 4) I moved ResolveIndirectFunction from ProcessPosix to Process since it works the exact same way on Mac OS X and the other posix systems. If we find a platform that doesn't do it this way, they can override the call in Process. 5) Fixed one bug in RunThreadPlan, if you were trying to run a thread plan after a "running" event had been broadcast, the event coalescing would cause you to miss the ThreadPlan running event. So I added a way to override the coalescing. 6) Made DynamicLoaderMacOSXDYLD::GetStepThroughTrampolinePlan handle Indirect & Re-exported symbols. <rdar://problem/15280639> llvm-svn: 198976
2014-01-11 07:46:59 +08:00
}
else
Have the Process hold a weak_ptr to the Target. llvm-svn: 246578
2015-09-02 04:02:29 +08:00
load_addr = owner->GetAddress().GetOpcodeLoadAddress (&GetTarget());
Get the breakpoint setting, and the Mac OS X DYLD trampolines and expression evaluator to handle Indirect symbols correctly. There were a couple of pieces to this. 1) When a breakpoint location finds itself pointing to an Indirect symbol, when the site for it is created it needs to resolve the symbol and actually set the site at its target. 2) Not all breakpoints want to do this (i.e. a straight address breakpoint should always set itself on the specified address, so somem machinery was needed to specify that. 3) I added some info to the break list output for indirect symbols so you could see what was happening. Also I made it clear when we re-route through re-exported symbols. 4) I moved ResolveIndirectFunction from ProcessPosix to Process since it works the exact same way on Mac OS X and the other posix systems. If we find a platform that doesn't do it this way, they can override the call in Process. 5) Fixed one bug in RunThreadPlan, if you were trying to run a thread plan after a "running" event had been broadcast, the event coalescing would cause you to miss the ThreadPlan running event. So I added a way to override the coalescing. 6) Made DynamicLoaderMacOSXDYLD::GetStepThroughTrampolinePlan handle Indirect & Re-exported symbols. <rdar://problem/15280639> llvm-svn: 198976
2014-01-11 07:46:59 +08:00
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)
{
<rdar://problem/13635174> Added a way to set hardware breakpoints from the "breakpoint set" command with the new "--hardware" option. Hardware breakpoints are not a request, they currently are a requirement. So when breakpoints are specified as hardware breakpoints, they might fail to be set when they are able to be resolved and should be used sparingly. This is currently hooked up for GDB remote debugging. Linux and FreeBSD should quickly enable this feature if possible, or return an error for any breakpoints that are hardware breakpoint sites in the "virtual Error Process::EnableBreakpointSite (BreakpointSite *bp_site);" function. llvm-svn: 192491
2013-10-12 03:48:25 +08:00
Error error = EnableBreakpointSite (bp_site_sp.get());
if (error.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);
}
<rdar://problem/13635174> Added a way to set hardware breakpoints from the "breakpoint set" command with the new "--hardware" option. Hardware breakpoints are not a request, they currently are a requirement. So when breakpoints are specified as hardware breakpoints, they might fail to be set when they are able to be resolved and should be used sparingly. This is currently hooked up for GDB remote debugging. Linux and FreeBSD should quickly enable this feature if possible, or return an error for any breakpoints that are hardware breakpoint sites in the "virtual Error Process::EnableBreakpointSite (BreakpointSite *bp_site);" function. llvm-svn: 192491
2013-10-12 03:48:25 +08:00
else
{
Expose SBPlatform through the public API. Example code: remote_platform = lldb.SBPlatform("remote-macosx"); remote_platform.SetWorkingDirectory("/private/tmp") debugger.SetSelectedPlatform(remote_platform) connect_options = lldb.SBPlatformConnectOptions("connect://localhost:1111"); err = remote_platform.ConnectRemote(connect_options) if err.Success(): print >> result, 'Connected to remote platform:' print >> result, 'hostname: %s' % (remote_platform.GetHostname()) src = lldb.SBFileSpec("/Applications/Xcode.app/Contents/SharedFrameworks/LLDB.framework", False) dst = lldb.SBFileSpec() # copy src to platform working directory since "dst" is empty err = remote_platform.Install(src, dst); if err.Success(): print >> result, '%s installed successfully' % (src) else: print >> result, 'error: failed to install "%s": %s' % (src, err) Implemented many calls needed in lldb-platform to be able to install a directory that contains symlinks, file and directories. The remote lldb-platform can now launch GDB servers on the remote system so that remote debugging can be spawned through the remote platform when connected to a remote platform. The API in SBPlatform is subject to change and will be getting many new functions. llvm-svn: 195273
2013-11-21 05:07:01 +08:00
if (show_error)
{
// Report error for setting breakpoint...
Have the Process hold a weak_ptr to the Target. llvm-svn: 246578
2015-09-02 04:02:29 +08:00
GetTarget().GetDebugger().GetErrorFile()->Printf ("warning: failed to set breakpoint site at 0x%" PRIx64 " for breakpoint %i.%i: %s\n",
load_addr,
owner->GetBreakpoint().GetID(),
owner->GetID(),
error.AsCString() ? error.AsCString() : "unknown error");
Expose SBPlatform through the public API. Example code: remote_platform = lldb.SBPlatform("remote-macosx"); remote_platform.SetWorkingDirectory("/private/tmp") debugger.SetSelectedPlatform(remote_platform) connect_options = lldb.SBPlatformConnectOptions("connect://localhost:1111"); err = remote_platform.ConnectRemote(connect_options) if err.Success(): print >> result, 'Connected to remote platform:' print >> result, 'hostname: %s' % (remote_platform.GetHostname()) src = lldb.SBFileSpec("/Applications/Xcode.app/Contents/SharedFrameworks/LLDB.framework", False) dst = lldb.SBFileSpec() # copy src to platform working directory since "dst" is empty err = remote_platform.Install(src, dst); if err.Success(): print >> result, '%s installed successfully' % (src) else: print >> result, 'error: failed to install "%s": %s' % (src, err) Implemented many calls needed in lldb-platform to be able to install a directory that contains symlinks, file and directories. The remote lldb-platform can now launch GDB servers on the remote system so that remote debugging can be spawned through the remote platform when connected to a remote platform. The API in SBPlatform is subject to change and will be getting many new functions. llvm-svn: 195273
2013-11-21 05:07:01 +08:00
}
<rdar://problem/13635174> Added a way to set hardware breakpoints from the "breakpoint set" command with the new "--hardware" option. Hardware breakpoints are not a request, they currently are a requirement. So when breakpoints are specified as hardware breakpoints, they might fail to be set when they are able to be resolved and should be used sparingly. This is currently hooked up for GDB remote debugging. Linux and FreeBSD should quickly enable this feature if possible, or return an error for any breakpoints that are hardware breakpoint sites in the "virtual Error Process::EnableBreakpointSite (BreakpointSite *bp_site);" function. llvm-svn: 192491
2013-10-12 03:48:25 +08:00
}
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
}
}
// We failed to enable the breakpoint
return LLDB_INVALID_BREAK_ID;
}
void
Process::RemoveOwnerFromBreakpointSite (lldb::user_id_t owner_id, lldb::user_id_t owner_loc_id, BreakpointSiteSP &bp_site_sp)
{
uint32_t num_owners = bp_site_sp->RemoveOwner (owner_id, owner_loc_id);
if (num_owners == 0)
{
Don't call DisableBreakpointSite (i.e. don't try to remove the breakpoint from the target process) if the target process is no longer alive. <rdar://problem/13320991> llvm-svn: 178936
2013-04-06 08:16:39 +08:00
// Don't try to disable the site if we don't have a live process anymore.
if (IsAlive())
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;
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
{
Huge performance improvements when one breakpoint contains many locations. 325,000 breakpoints for running "breakpoint set --func-regex ." on lldb itself (after hitting a breakpoint at main so that LLDB.framework is loaded) used to take up to an hour to set, now we are down under a minute. With warm file caches, we are at 40 seconds, and that is with setting 325,000 breakpoint through the GDB remote API. Linux and the native debuggers might be faster. I haven't timed what how much is debug info parsing and how much is the protocol traffic to/from GDB remote. That there were many performance issues. Most of them were due to storing breakpoints in the wrong data structures, or using the wrong iterators to traverse the lists, traversing the lists in inefficient ways, and not optimizing certain function name lookups/symbol merges correctly. Debugging after that is also now very efficient. There were issues with replacing the breakpoint opcodes in memory that was read, and those routines were also fixed. llvm-svn: 183820
2013-06-12 08:46:38 +08:00
bp_sites_in_range.ForEach([bp_addr, size, buf, &bytes_removed](BreakpointSite *bp_site) -> void {
if (bp_site->GetType() == BreakpointSite::eSoftware)
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
{
Huge performance improvements when one breakpoint contains many locations. 325,000 breakpoints for running "breakpoint set --func-regex ." on lldb itself (after hitting a breakpoint at main so that LLDB.framework is loaded) used to take up to an hour to set, now we are down under a minute. With warm file caches, we are at 40 seconds, and that is with setting 325,000 breakpoint through the GDB remote API. Linux and the native debuggers might be faster. I haven't timed what how much is debug info parsing and how much is the protocol traffic to/from GDB remote. That there were many performance issues. Most of them were due to storing breakpoints in the wrong data structures, or using the wrong iterators to traverse the lists, traversing the lists in inefficient ways, and not optimizing certain function name lookups/symbol merges correctly. Debugging after that is also now very efficient. There were issues with replacing the breakpoint opcodes in memory that was read, and those routines were also fixed. llvm-svn: 183820
2013-06-12 08:46:38 +08:00
addr_t intersect_addr;
size_t intersect_size;
size_t opcode_offset;
if (bp_site->IntersectsRange(bp_addr, size, &intersect_addr, &intersect_size, &opcode_offset))
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);
Huge performance improvements when one breakpoint contains many locations. 325,000 breakpoints for running "breakpoint set --func-regex ." on lldb itself (after hitting a breakpoint at main so that LLDB.framework is loaded) used to take up to an hour to set, now we are down under a minute. With warm file caches, we are at 40 seconds, and that is with setting 325,000 breakpoint through the GDB remote API. Linux and the native debuggers might be faster. I haven't timed what how much is debug info parsing and how much is the protocol traffic to/from GDB remote. That there were many performance issues. Most of them were due to storing breakpoints in the wrong data structures, or using the wrong iterators to traverse the lists, traversing the lists in inefficient ways, and not optimizing certain function name lookups/symbol merges correctly. Debugging after that is also now very efficient. There were issues with replacing the breakpoint opcodes in memory that was read, and those routines were also fixed. llvm-svn: 183820
2013-06-12 08:46:38 +08:00
assert(opcode_offset + intersect_size <= bp_site->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;
Huge performance improvements when one breakpoint contains many locations. 325,000 breakpoints for running "breakpoint set --func-regex ." on lldb itself (after hitting a breakpoint at main so that LLDB.framework is loaded) used to take up to an hour to set, now we are down under a minute. With warm file caches, we are at 40 seconds, and that is with setting 325,000 breakpoint through the GDB remote API. Linux and the native debuggers might be faster. I haven't timed what how much is debug info parsing and how much is the protocol traffic to/from GDB remote. That there were many performance issues. Most of them were due to storing breakpoints in the wrong data structures, or using the wrong iterators to traverse the lists, traversing the lists in inefficient ways, and not optimizing certain function name lookups/symbol merges correctly. Debugging after that is also now very efficient. There were issues with replacing the breakpoint opcodes in memory that was read, and those routines were also fixed. llvm-svn: 183820
2013-06-12 08:46:38 +08:00
::memcpy(buf + buf_offset, bp_site->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
}
Huge performance improvements when one breakpoint contains many locations. 325,000 breakpoints for running "breakpoint set --func-regex ." on lldb itself (after hitting a breakpoint at main so that LLDB.framework is loaded) used to take up to an hour to set, now we are down under a minute. With warm file caches, we are at 40 seconds, and that is with setting 325,000 breakpoint through the GDB remote API. Linux and the native debuggers might be faster. I haven't timed what how much is debug info parsing and how much is the protocol traffic to/from GDB remote. That there were many performance issues. Most of them were due to storing breakpoints in the wrong data structures, or using the wrong iterators to traverse the lists, traversing the lists in inefficient ways, and not optimizing certain function name lookups/symbol merges correctly. Debugging after that is also now very efficient. There were issues with replacing the breakpoint opcodes in memory that was read, and those routines were also fixed. llvm-svn: 183820
2013-06-12 08:46:38 +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)
{
Have the Process hold a weak_ptr to the Target. llvm-svn: 246578
2015-09-02 04:02:29 +08:00
PlatformSP platform_sp (GetTarget().GetPlatform());
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
if (platform_sp)
Have the Process hold a weak_ptr to the Target. llvm-svn: 246578
2015-09-02 04:02:29 +08:00
return platform_sp->GetSoftwareBreakpointTrapOpcode (GetTarget(), bp_site);
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
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)
{
Fix typos. llvm-svn: 212132
2014-07-02 05:22:11 +08:00
// Clear a software breakpoint 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;
Fix a variety of typos. No functional change. llvm-svn: 239995
2015-06-18 13:27:05 +08:00
// Make sure the breakpoint opcode exists at this address
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
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)
{
Commit a work-in-progress system runtime for Mac OS X which won't do anything right now. Add a few new methods to the Thread base class which HistoryThread needs. I think I updated all the CMakeLists files correctly for the new plugin. llvm-svn: 194756
2013-11-15 08:17:32 +08:00
error.Clear();
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();
}
Provided a variant of ReadCStringFromMemory that supports null terminators of any character width. This prevents unbounded reads (i.e. reads of GetMaximumSizeOfStringSummary() bytes) from causing test failures (i.e. due to ptrace EIO or EFAULT on Linux). Note that ReadCStringFromMemory is marked as deprecated because the loop that calls ReadMemory does not continue until the string has been completely read. The expected behavior is to read until until max_bytes or a null terminator. Note: As discussed on lldb-dev, further testing will be performed with ReadStringFromMemory before further changes are made for users of ReadCStringFromMemory. Thanks to Enrico, Matt and Andy for their review feedback. llvm-svn: 179857
2013-04-19 23:58:38 +08:00
size_t
Process::ReadStringFromMemory (addr_t addr, char *dst, size_t max_bytes, Error &error,
size_t type_width)
{
size_t total_bytes_read = 0;
if (dst && max_bytes && type_width && max_bytes >= type_width)
{
// Ensure a null terminator independent of the number of bytes that is read.
memset (dst, 0, max_bytes);
size_t bytes_left = max_bytes - type_width;
const char terminator[4] = {'\0', '\0', '\0', '\0'};
assert(sizeof(terminator) >= type_width &&
"Attempting to validate a string with more than 4 bytes per character!");
addr_t curr_addr = addr;
const size_t cache_line_size = m_memory_cache.GetMemoryCacheLineSize();
char *curr_dst = dst;
error.Clear();
while (bytes_left > 0 && error.Success())
{
addr_t cache_line_bytes_left = cache_line_size - (curr_addr % cache_line_size);
addr_t bytes_to_read = std::min<addr_t>(bytes_left, cache_line_bytes_left);
size_t bytes_read = ReadMemory (curr_addr, curr_dst, bytes_to_read, error);
if (bytes_read == 0)
break;
// Search for a null terminator of correct size and alignment in bytes_read
size_t aligned_start = total_bytes_read - total_bytes_read % type_width;
for (size_t i = aligned_start; i + type_width <= total_bytes_read + bytes_read; i += type_width)
if (::strncmp(&dst[i], terminator, type_width) == 0)
{
error.Clear();
return i;
}
total_bytes_read += bytes_read;
curr_dst += bytes_read;
curr_addr += bytes_read;
bytes_left -= bytes_read;
}
}
else
{
if (max_bytes)
error.SetErrorString("invalid arguments");
}
return total_bytes_read;
}
// Deprecated in favor of ReadStringFromMemory which has wchar support and correct code to find
// null terminators.
Moved the execution context that was in the Debugger into the CommandInterpreter where it was always being used. Make sure that Modules can track their object file offsets correctly to allow opening of sub object files (like the "__commpage" on darwin). Modified the Platforms to be able to launch processes. The first part of this move is the platform soon will become the entity that launches your program and when it does, it uses a new ProcessLaunchInfo class which encapsulates all process launching settings. This simplifies the internal APIs needed for launching. I want to slowly phase out process launching from the process classes, so for now we can still launch just as we used to, but eventually the platform is the object that should do the launching. Modified the Host::LaunchProcess in the MacOSX Host.mm to correctly be able to launch processes with all of the new eLaunchFlag settings. Modified any code that was manually launching processes to use the Host::LaunchProcess functions. Fixed an issue where lldb_private::Args had implicitly defined copy constructors that could do the wrong thing. This has now been fixed by adding an appropriate copy constructor and assignment operator. Make sure we don't add empty ModuleSP entries to a module list. Fixed the commpage module creation on MacOSX, but we still need to train the MacOSX dynamic loader to not get rid of it when it doesn't have an entry in the all image infos. Abstracted many more calls from in ProcessGDBRemote down into the GDBRemoteCommunicationClient subclass to make the classes cleaner and more efficient. Fixed the default iOS ARM register context to be correct and also added support for targets that don't support the qThreadStopInfo packet by selecting the current thread (only if needed) and then sending a stop reply packet. Debugserver can now start up with a --unix-socket (-u for short) and can then bind to port zero and send the port it bound to to a listening process on the other end. This allows the GDB remote platform to spawn new GDB server instances (debugserver) to allow platform debugging. llvm-svn: 129351
2011-04-12 13:54:46 +08:00
size_t
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.
Huge performance improvements when one breakpoint contains many locations. 325,000 breakpoints for running "breakpoint set --func-regex ." on lldb itself (after hitting a breakpoint at main so that LLDB.framework is loaded) used to take up to an hour to set, now we are down under a minute. With warm file caches, we are at 40 seconds, and that is with setting 325,000 breakpoint through the GDB remote API. Linux and the native debuggers might be faster. I haven't timed what how much is debug info parsing and how much is the protocol traffic to/from GDB remote. That there were many performance issues. Most of them were due to storing breakpoints in the wrong data structures, or using the wrong iterators to traverse the lists, traversing the lists in inefficient ways, and not optimizing certain function name lookups/symbol merges correctly. Debugging after that is also now very efficient. There were issues with replacing the breakpoint opcodes in memory that was read, and those routines were also fixed. llvm-svn: 183820
2013-06-12 08:46:38 +08:00
BreakpointSiteList bp_sites_in_range;
if (m_breakpoint_site_list.FindInRange (addr, 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
{
Huge performance improvements when one breakpoint contains many locations. 325,000 breakpoints for running "breakpoint set --func-regex ." on lldb itself (after hitting a breakpoint at main so that LLDB.framework is loaded) used to take up to an hour to set, now we are down under a minute. With warm file caches, we are at 40 seconds, and that is with setting 325,000 breakpoint through the GDB remote API. Linux and the native debuggers might be faster. I haven't timed what how much is debug info parsing and how much is the protocol traffic to/from GDB remote. That there were many performance issues. Most of them were due to storing breakpoints in the wrong data structures, or using the wrong iterators to traverse the lists, traversing the lists in inefficient ways, and not optimizing certain function name lookups/symbol merges correctly. Debugging after that is also now very efficient. There were issues with replacing the breakpoint opcodes in memory that was read, and those routines were also fixed. llvm-svn: 183820
2013-06-12 08:46:38 +08:00
// No breakpoint sites overlap
if (bp_sites_in_range.IsEmpty())
return WriteMemoryPrivate (addr, buf, size, error);
else
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
{
Huge performance improvements when one breakpoint contains many locations. 325,000 breakpoints for running "breakpoint set --func-regex ." on lldb itself (after hitting a breakpoint at main so that LLDB.framework is loaded) used to take up to an hour to set, now we are down under a minute. With warm file caches, we are at 40 seconds, and that is with setting 325,000 breakpoint through the GDB remote API. Linux and the native debuggers might be faster. I haven't timed what how much is debug info parsing and how much is the protocol traffic to/from GDB remote. That there were many performance issues. Most of them were due to storing breakpoints in the wrong data structures, or using the wrong iterators to traverse the lists, traversing the lists in inefficient ways, and not optimizing certain function name lookups/symbol merges correctly. Debugging after that is also now very efficient. There were issues with replacing the breakpoint opcodes in memory that was read, and those routines were also fixed. llvm-svn: 183820
2013-06-12 08:46:38 +08:00
const uint8_t *ubuf = (const uint8_t *)buf;
uint64_t bytes_written = 0;
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
Huge performance improvements when one breakpoint contains many locations. 325,000 breakpoints for running "breakpoint set --func-regex ." on lldb itself (after hitting a breakpoint at main so that LLDB.framework is loaded) used to take up to an hour to set, now we are down under a minute. With warm file caches, we are at 40 seconds, and that is with setting 325,000 breakpoint through the GDB remote API. Linux and the native debuggers might be faster. I haven't timed what how much is debug info parsing and how much is the protocol traffic to/from GDB remote. That there were many performance issues. Most of them were due to storing breakpoints in the wrong data structures, or using the wrong iterators to traverse the lists, traversing the lists in inefficient ways, and not optimizing certain function name lookups/symbol merges correctly. Debugging after that is also now very efficient. There were issues with replacing the breakpoint opcodes in memory that was read, and those routines were also fixed. llvm-svn: 183820
2013-06-12 08:46:38 +08:00
bp_sites_in_range.ForEach([this, addr, size, &bytes_written, &ubuf, &error](BreakpointSite *bp) -> void {
if (error.Success())
{
addr_t intersect_addr;
size_t intersect_size;
size_t opcode_offset;
const bool intersects = bp->IntersectsRange(addr, size, &intersect_addr, &intersect_size, &opcode_offset);
Add UNUSED_IF_ASSERT_DISABLED and apply it. Summary: This replaces (void)x; usages where they x was subsequently involved in an assertion with this macro to make the intent more clear. Reviewers: clayborg Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D11451 llvm-svn: 243074
2015-07-24 08:23:29 +08:00
UNUSED_IF_ASSERT_DISABLED(intersects);
Huge performance improvements when one breakpoint contains many locations. 325,000 breakpoints for running "breakpoint set --func-regex ." on lldb itself (after hitting a breakpoint at main so that LLDB.framework is loaded) used to take up to an hour to set, now we are down under a minute. With warm file caches, we are at 40 seconds, and that is with setting 325,000 breakpoint through the GDB remote API. Linux and the native debuggers might be faster. I haven't timed what how much is debug info parsing and how much is the protocol traffic to/from GDB remote. That there were many performance issues. Most of them were due to storing breakpoints in the wrong data structures, or using the wrong iterators to traverse the lists, traversing the lists in inefficient ways, and not optimizing certain function name lookups/symbol merges correctly. Debugging after that is also now very efficient. There were issues with replacing the breakpoint opcodes in memory that was read, and those routines were also fixed. llvm-svn: 183820
2013-06-12 08:46:38 +08:00
assert(intersects);
assert(addr <= intersect_addr && intersect_addr < addr + size);
assert(addr < intersect_addr + intersect_size && intersect_addr + intersect_size <= addr + size);
assert(opcode_offset + intersect_size <= bp->GetByteSize());
// Check for bytes before this breakpoint
const addr_t curr_addr = addr + bytes_written;
if (intersect_addr > curr_addr)
{
// There are some bytes before this breakpoint that we need to
// just write to memory
size_t curr_size = intersect_addr - curr_addr;
size_t curr_bytes_written = WriteMemoryPrivate (curr_addr,
ubuf + bytes_written,
curr_size,
error);
bytes_written += curr_bytes_written;
if (curr_bytes_written != curr_size)
{
// We weren't able to write all of the requested bytes, we
// are done looping and will return the number of bytes that
// we have written so far.
if (error.Success())
error.SetErrorToGenericError();
}
}
// Now write any bytes that would cover up any software breakpoints
// directly into the breakpoint opcode buffer
::memcpy(bp->GetSavedOpcodeBytes() + opcode_offset, ubuf + bytes_written, intersect_size);
bytes_written += intersect_size;
}
});
if (bytes_written < size)
Remove dead store. clang static analyzer fixit. llvm-svn: 219907
2014-10-16 15:49:27 +08:00
WriteMemoryPrivate (addr + bytes_written,
ubuf + bytes_written,
size - bytes_written,
error);
Huge performance improvements when one breakpoint contains many locations. 325,000 breakpoints for running "breakpoint set --func-regex ." on lldb itself (after hitting a breakpoint at main so that LLDB.framework is loaded) used to take up to an hour to set, now we are down under a minute. With warm file caches, we are at 40 seconds, and that is with setting 325,000 breakpoint through the GDB remote API. Linux and the native debuggers might be faster. I haven't timed what how much is debug info parsing and how much is the protocol traffic to/from GDB remote. That there were many performance issues. Most of them were due to storing breakpoints in the wrong data structures, or using the wrong iterators to traverse the lists, traversing the lists in inefficient ways, and not optimizing certain function name lookups/symbol merges correctly. Debugging after that is also now very efficient. There were issues with replacing the breakpoint opcodes in memory that was read, and those routines were also fixed. llvm-svn: 183820
2013-06-12 08:46:38 +08:00
}
}
else
{
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
}
// Write any remaining bytes after the last breakpoint if we have any left
Huge performance improvements when one breakpoint contains many locations. 325,000 breakpoints for running "breakpoint set --func-regex ." on lldb itself (after hitting a breakpoint at main so that LLDB.framework is loaded) used to take up to an hour to set, now we are down under a minute. With warm file caches, we are at 40 seconds, and that is with setting 325,000 breakpoint through the GDB remote API. Linux and the native debuggers might be faster. I haven't timed what how much is debug info parsing and how much is the protocol traffic to/from GDB remote. That there were many performance issues. Most of them were due to storing breakpoints in the wrong data structures, or using the wrong iterators to traverse the lists, traversing the lists in inefficient ways, and not optimizing certain function name lookups/symbol merges correctly. Debugging after that is also now very efficient. There were issues with replacing the breakpoint opcodes in memory that was read, and those routines were also fixed. llvm-svn: 183820
2013-06-12 08:46:38 +08:00
return 0; //bytes_written;
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +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
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)
{
Return zero when we don't support the byte size. Previously is we were asked to read 3, 5, 6, or 7 byte integers, we would set the error, but still return that we read that number of bytes without populating the scalar. llvm-svn: 180896
2013-05-02 07:41:30 +08:00
uint64_t uval = 0;
if (byte_size == 0)
{
error.SetErrorString ("byte size is zero");
}
else if (byte_size & (byte_size - 1))
Added new lldb_private::Process memory read/write functions to stop a bunch of duplicated code from appearing all over LLDB: lldb::addr_t Process::ReadPointerFromMemory (lldb::addr_t vm_addr, Error &error); bool Process::WritePointerToMemory (lldb::addr_t vm_addr, lldb::addr_t ptr_value, Error &error); size_t Process::ReadScalarIntegerFromMemory (lldb::addr_t addr, uint32_t byte_size, bool is_signed, Scalar &scalar, Error &error); size_t Process::WriteScalarToMemory (lldb::addr_t vm_addr, const Scalar &scalar, uint32_t size, Error &error); in lldb_private::Process the following functions were renamed: From: uint64_t Process::ReadUnsignedInteger (lldb::addr_t load_addr, size_t byte_size, Error &error); To: uint64_t Process::ReadUnsignedIntegerFromMemory (lldb::addr_t load_addr, size_t byte_size, uint64_t fail_value, Error &error); Cleaned up a lot of code that was manually doing what the above functions do to use the functions listed above. Added the ability to get a scalar value as a buffer that can be written down to a process (byte swapping the Scalar value if needed): uint32_t Scalar::GetAsMemoryData (void *dst, uint32_t dst_len, lldb::ByteOrder dst_byte_order, Error &error) const; The "dst_len" can be smaller that the size of the scalar and the least significant bytes will be written. "dst_len" can also be larger and the most significant bytes will be padded with zeroes. Centralized the code that adds or removes address bits for callable and opcode addresses into lldb_private::Target: lldb::addr_t Target::GetCallableLoadAddress (lldb::addr_t load_addr, AddressClass addr_class) const; lldb::addr_t Target::GetOpcodeLoadAddress (lldb::addr_t load_addr, AddressClass addr_class) const; All necessary lldb_private::Address functions now use the target versions so changes should only need to happen in one place if anything needs updating. Fixed up a lot of places that were calling : addr_t Address::GetLoadAddress(Target*); to call the Address::GetCallableLoadAddress() or Address::GetOpcodeLoadAddress() as needed. There were many places in the breakpoint code where things could go wrong for ARM if these weren't used. llvm-svn: 131878
2011-05-23 06:46:53 +08:00
{
Return zero when we don't support the byte size. Previously is we were asked to read 3, 5, 6, or 7 byte integers, we would set the error, but still return that we read that number of bytes without populating the scalar. llvm-svn: 180896
2013-05-02 07:41:30 +08:00
error.SetErrorStringWithFormat ("byte size %u is not a power of 2", byte_size);
}
else if (byte_size <= sizeof(uval))
{
const size_t bytes_read = ReadMemory (addr, &uval, byte_size, error);
Added new lldb_private::Process memory read/write functions to stop a bunch of duplicated code from appearing all over LLDB: lldb::addr_t Process::ReadPointerFromMemory (lldb::addr_t vm_addr, Error &error); bool Process::WritePointerToMemory (lldb::addr_t vm_addr, lldb::addr_t ptr_value, Error &error); size_t Process::ReadScalarIntegerFromMemory (lldb::addr_t addr, uint32_t byte_size, bool is_signed, Scalar &scalar, Error &error); size_t Process::WriteScalarToMemory (lldb::addr_t vm_addr, const Scalar &scalar, uint32_t size, Error &error); in lldb_private::Process the following functions were renamed: From: uint64_t Process::ReadUnsignedInteger (lldb::addr_t load_addr, size_t byte_size, Error &error); To: uint64_t Process::ReadUnsignedIntegerFromMemory (lldb::addr_t load_addr, size_t byte_size, uint64_t fail_value, Error &error); Cleaned up a lot of code that was manually doing what the above functions do to use the functions listed above. Added the ability to get a scalar value as a buffer that can be written down to a process (byte swapping the Scalar value if needed): uint32_t Scalar::GetAsMemoryData (void *dst, uint32_t dst_len, lldb::ByteOrder dst_byte_order, Error &error) const; The "dst_len" can be smaller that the size of the scalar and the least significant bytes will be written. "dst_len" can also be larger and the most significant bytes will be padded with zeroes. Centralized the code that adds or removes address bits for callable and opcode addresses into lldb_private::Target: lldb::addr_t Target::GetCallableLoadAddress (lldb::addr_t load_addr, AddressClass addr_class) const; lldb::addr_t Target::GetOpcodeLoadAddress (lldb::addr_t load_addr, AddressClass addr_class) const; All necessary lldb_private::Address functions now use the target versions so changes should only need to happen in one place if anything needs updating. Fixed up a lot of places that were calling : addr_t Address::GetLoadAddress(Target*); to call the Address::GetCallableLoadAddress() or Address::GetOpcodeLoadAddress() as needed. There were many places in the breakpoint code where things could go wrong for ARM if these weren't used. llvm-svn: 131878
2011-05-23 06:46:53 +08:00
if (bytes_read == byte_size)
{
DataExtractor data (&uval, sizeof(uval), GetByteOrder(), GetAddressByteSize());
<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;
Return zero when we don't support the byte size. Previously is we were asked to read 3, 5, 6, or 7 byte integers, we would set the error, but still return that we read that number of bytes without populating the scalar. llvm-svn: 180896
2013-05-02 07:41:30 +08:00
if (byte_size <= 4)
scalar = data.GetMaxU32 (&offset, byte_size);
Added new lldb_private::Process memory read/write functions to stop a bunch of duplicated code from appearing all over LLDB: lldb::addr_t Process::ReadPointerFromMemory (lldb::addr_t vm_addr, Error &error); bool Process::WritePointerToMemory (lldb::addr_t vm_addr, lldb::addr_t ptr_value, Error &error); size_t Process::ReadScalarIntegerFromMemory (lldb::addr_t addr, uint32_t byte_size, bool is_signed, Scalar &scalar, Error &error); size_t Process::WriteScalarToMemory (lldb::addr_t vm_addr, const Scalar &scalar, uint32_t size, Error &error); in lldb_private::Process the following functions were renamed: From: uint64_t Process::ReadUnsignedInteger (lldb::addr_t load_addr, size_t byte_size, Error &error); To: uint64_t Process::ReadUnsignedIntegerFromMemory (lldb::addr_t load_addr, size_t byte_size, uint64_t fail_value, Error &error); Cleaned up a lot of code that was manually doing what the above functions do to use the functions listed above. Added the ability to get a scalar value as a buffer that can be written down to a process (byte swapping the Scalar value if needed): uint32_t Scalar::GetAsMemoryData (void *dst, uint32_t dst_len, lldb::ByteOrder dst_byte_order, Error &error) const; The "dst_len" can be smaller that the size of the scalar and the least significant bytes will be written. "dst_len" can also be larger and the most significant bytes will be padded with zeroes. Centralized the code that adds or removes address bits for callable and opcode addresses into lldb_private::Target: lldb::addr_t Target::GetCallableLoadAddress (lldb::addr_t load_addr, AddressClass addr_class) const; lldb::addr_t Target::GetOpcodeLoadAddress (lldb::addr_t load_addr, AddressClass addr_class) const; All necessary lldb_private::Address functions now use the target versions so changes should only need to happen in one place if anything needs updating. Fixed up a lot of places that were calling : addr_t Address::GetLoadAddress(Target*); to call the Address::GetCallableLoadAddress() or Address::GetOpcodeLoadAddress() as needed. There were many places in the breakpoint code where things could go wrong for ARM if these weren't used. llvm-svn: 131878
2011-05-23 06:46:53 +08:00
else
Return zero when we don't support the byte size. Previously is we were asked to read 3, 5, 6, or 7 byte integers, we would set the error, but still return that we read that number of bytes without populating the scalar. llvm-svn: 180896
2013-05-02 07:41:30 +08:00
scalar = data.GetMaxU64 (&offset, byte_size);
Added new lldb_private::Process memory read/write functions to stop a bunch of duplicated code from appearing all over LLDB: lldb::addr_t Process::ReadPointerFromMemory (lldb::addr_t vm_addr, Error &error); bool Process::WritePointerToMemory (lldb::addr_t vm_addr, lldb::addr_t ptr_value, Error &error); size_t Process::ReadScalarIntegerFromMemory (lldb::addr_t addr, uint32_t byte_size, bool is_signed, Scalar &scalar, Error &error); size_t Process::WriteScalarToMemory (lldb::addr_t vm_addr, const Scalar &scalar, uint32_t size, Error &error); in lldb_private::Process the following functions were renamed: From: uint64_t Process::ReadUnsignedInteger (lldb::addr_t load_addr, size_t byte_size, Error &error); To: uint64_t Process::ReadUnsignedIntegerFromMemory (lldb::addr_t load_addr, size_t byte_size, uint64_t fail_value, Error &error); Cleaned up a lot of code that was manually doing what the above functions do to use the functions listed above. Added the ability to get a scalar value as a buffer that can be written down to a process (byte swapping the Scalar value if needed): uint32_t Scalar::GetAsMemoryData (void *dst, uint32_t dst_len, lldb::ByteOrder dst_byte_order, Error &error) const; The "dst_len" can be smaller that the size of the scalar and the least significant bytes will be written. "dst_len" can also be larger and the most significant bytes will be padded with zeroes. Centralized the code that adds or removes address bits for callable and opcode addresses into lldb_private::Target: lldb::addr_t Target::GetCallableLoadAddress (lldb::addr_t load_addr, AddressClass addr_class) const; lldb::addr_t Target::GetOpcodeLoadAddress (lldb::addr_t load_addr, AddressClass addr_class) const; All necessary lldb_private::Address functions now use the target versions so changes should only need to happen in one place if anything needs updating. Fixed up a lot of places that were calling : addr_t Address::GetLoadAddress(Target*); to call the Address::GetCallableLoadAddress() or Address::GetOpcodeLoadAddress() as needed. There were many places in the breakpoint code where things could go wrong for ARM if these weren't used. llvm-svn: 131878
2011-05-23 06:46:53 +08:00
if (is_signed)
scalar.SignExtend(byte_size * 8);
return bytes_read;
}
}
else
{
error.SetErrorStringWithFormat ("byte size of %u is too large for integer scalar type", byte_size);
}
return 0;
}
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)
Fixed format strings as they still must specicy a '%' prior to using PRI*64 macros. llvm-svn: 193260
2013-10-24 02:24:30 +08:00
log->Printf("Process::AllocateMemory(size=%" PRIu64 ", permissions=%s) => 0x%16.16" PRIx64 " (m_stop_id = %u m_memory_id = %u)",
Fixes to get LLDB building on Windows again. llvm-svn: 193159
2013-10-22 20:27:43 +08:00
(uint64_t)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
}
Add "zero_memory" option to IRMemoryMap::FindSpace & IRMemoryMap::Malloc. Zero out the Expression ResultVariable so it's in a known initial state. llvm-svn: 252072
2015-11-05 04:32:27 +08:00
addr_t
Process::CallocateMemory(size_t size, uint32_t permissions, Error &error)
{
addr_t return_addr = AllocateMemory(size, permissions, error);
if (error.Success())
{
std::string buffer(size, 0);
WriteMemory(return_addr, buffer.c_str(), size, error);
}
return return_addr;
}
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)
{
Add lldb-gdbserver support for Linux x86_64. This change brings in lldb-gdbserver (llgs) specifically for Linux x86_64. (More architectures coming soon). Not every debugserver option is covered yet. Currently the lldb-gdbserver command line can start unattached, start attached to a pid (process-name attach not supported yet), or accept lldb attaching and launching a process or connecting by process id. The history of this large change can be found here: https://github.com/tfiala/lldb/tree/dev-tfiala-native-protocol-linux-x86_64 Until mid/late April, I was not sharing the work and continued to rebase it off of head (developed via id tfiala@google.com). I switched over to user todd.fiala@gmail.com in the middle, and once I went to github, I did merges rather than rebasing so I could share with others. llvm-svn: 212069
2014-07-01 05:05:18 +08:00
Log *log(lldb_private::GetLogIfAllCategoriesSet (LIBLLDB_LOG_PROCESS));
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
Error err;
uint64_t allocated_memory = AllocateMemory(8,
ePermissionsReadable | ePermissionsWritable | ePermissionsExecutable,
err);
if (err.Success())
Add lldb-gdbserver support for Linux x86_64. This change brings in lldb-gdbserver (llgs) specifically for Linux x86_64. (More architectures coming soon). Not every debugserver option is covered yet. Currently the lldb-gdbserver command line can start unattached, start attached to a pid (process-name attach not supported yet), or accept lldb attaching and launching a process or connecting by process id. The history of this large change can be found here: https://github.com/tfiala/lldb/tree/dev-tfiala-native-protocol-linux-x86_64 Until mid/late April, I was not sharing the work and continued to rebase it off of head (developed via id tfiala@google.com). I switched over to user todd.fiala@gmail.com in the middle, and once I went to github, I did merges rather than rebasing so I could share with others. llvm-svn: 212069
2014-07-01 05:05:18 +08:00
{
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
m_can_jit = eCanJITYes;
Add lldb-gdbserver support for Linux x86_64. This change brings in lldb-gdbserver (llgs) specifically for Linux x86_64. (More architectures coming soon). Not every debugserver option is covered yet. Currently the lldb-gdbserver command line can start unattached, start attached to a pid (process-name attach not supported yet), or accept lldb attaching and launching a process or connecting by process id. The history of this large change can be found here: https://github.com/tfiala/lldb/tree/dev-tfiala-native-protocol-linux-x86_64 Until mid/late April, I was not sharing the work and continued to rebase it off of head (developed via id tfiala@google.com). I switched over to user todd.fiala@gmail.com in the middle, and once I went to github, I did merges rather than rebasing so I could share with others. llvm-svn: 212069
2014-07-01 05:05:18 +08:00
if (log)
log->Printf ("Process::%s pid %" PRIu64 " allocation test passed, CanJIT () is true", __FUNCTION__, GetID ());
}
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
else
Add lldb-gdbserver support for Linux x86_64. This change brings in lldb-gdbserver (llgs) specifically for Linux x86_64. (More architectures coming soon). Not every debugserver option is covered yet. Currently the lldb-gdbserver command line can start unattached, start attached to a pid (process-name attach not supported yet), or accept lldb attaching and launching a process or connecting by process id. The history of this large change can be found here: https://github.com/tfiala/lldb/tree/dev-tfiala-native-protocol-linux-x86_64 Until mid/late April, I was not sharing the work and continued to rebase it off of head (developed via id tfiala@google.com). I switched over to user todd.fiala@gmail.com in the middle, and once I went to github, I did merges rather than rebasing so I could share with others. llvm-svn: 212069
2014-07-01 05:05:18 +08:00
{
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
m_can_jit = eCanJITNo;
Add lldb-gdbserver support for Linux x86_64. This change brings in lldb-gdbserver (llgs) specifically for Linux x86_64. (More architectures coming soon). Not every debugserver option is covered yet. Currently the lldb-gdbserver command line can start unattached, start attached to a pid (process-name attach not supported yet), or accept lldb attaching and launching a process or connecting by process id. The history of this large change can be found here: https://github.com/tfiala/lldb/tree/dev-tfiala-native-protocol-linux-x86_64 Until mid/late April, I was not sharing the work and continued to rebase it off of head (developed via id tfiala@google.com). I switched over to user todd.fiala@gmail.com in the middle, and once I went to github, I did merges rather than rebasing so I could share with others. llvm-svn: 212069
2014-07-01 05:05:18 +08:00
if (log)
log->Printf ("Process::%s pid %" PRIu64 " allocation test failed, CanJIT () is false: %s", __FUNCTION__, GetID (), err.AsCString ());
}
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
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);
}
Expression evaluation, a new ThreadPlanCallFunctionUsingABI for executing a function call on target via register manipulation For Hexagon we want to be able to call functions during debugging, however currently lldb only supports this when there is JIT support. Although emulation using IR interpretation is an alternative, it is currently limited in that it can't make function calls. In this patch we have extended the IR interpreter so that it can execute a function call on the target using register manipulation. To do this we need to handle the Call IR instruction, passing arguments to a new thread plan and collecting any return values to pass back into the IR interpreter. The new thread plan is needed to call an alternative ABI interface of "ABI::PerpareTrivialCall()", allowing more detailed information about arguments and return values. Reviewers: jingham, spyffe Subscribers: emaste, lldb-commits, ted, ADodds, deepak2427 Differential Revision: http://reviews.llvm.org/D9404 llvm-svn: 242137
2015-07-14 18:56:58 +08:00
void
Process::SetCanRunCode (bool can_run_code)
{
SetCanJIT(can_run_code);
m_can_interpret_function_calls = can_run_code;
}
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
}
<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,
Add support for JIT debugging on Linux using the GDB JIT interface. Patch written with Keno Fischer. llvm-svn: 202956
2014-03-05 18:12:43 +08:00
lldb::addr_t header_addr,
size_t size_to_read)
<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
{
Add some initial logging for when lldb is searching for binaries, dSYMs, or reading binaries out of memory to the 'Host' log channel. There's more to be done here, both for Mac and for other platforms, but the initial set of new loggings are useful enough to check in at this point. llvm-svn: 243200
2015-07-25 10:39:42 +08:00
Log *log = lldb_private::GetLogIfAllCategoriesSet(LIBLLDB_LOG_HOST);
if (log)
{
log->Printf ("Process::ReadModuleFromMemory reading %s binary from memory", file_spec.GetPath().c_str());
}
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;
Add support for JIT debugging on Linux using the GDB JIT interface. Patch written with Keno Fischer. llvm-svn: 202956
2014-03-05 18:12:43 +08:00
ObjectFile *objfile = module_sp->GetMemoryObjectFile (shared_from_this(), header_addr, error, size_to_read);
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
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
Further reduce the header footprint of Process.h No functional change here, only deletes unnecessary headers and moves one function's body from the .h file to the .cpp. llvm-svn: 231145
2015-03-04 05:51:25 +08:00
bool
Process::GetLoadAddressPermissions (lldb::addr_t load_addr, uint32_t &permissions)
{
MemoryRegionInfo range_info;
permissions = 0;
Error error (GetMemoryRegionInfo (load_addr, range_info));
if (!error.Success())
return false;
if (range_info.GetReadable() == MemoryRegionInfo::eDontKnow
|| range_info.GetWritable() == MemoryRegionInfo::eDontKnow
|| range_info.GetExecutable() == MemoryRegionInfo::eDontKnow)
{
return false;
}
if (range_info.GetReadable() == MemoryRegionInfo::eYes)
permissions |= lldb::ePermissionsReadable;
if (range_info.GetWritable() == MemoryRegionInfo::eYes)
permissions |= lldb::ePermissionsWritable;
if (range_info.GetExecutable() == MemoryRegionInfo::eYes)
permissions |= lldb::ePermissionsExecutable;
return true;
}
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;
}
Fixed an issue where if the operating system python plug-in is changed at runtime, it wouldn't cause the process to reload the new operating system plug-in, now it does. This is currently controlled by a setting: (lldb) settings set target.process.python-os-plugin-path <path> Or clearing it with: (lldb) settings clear target.process.python-os-plugin-path The process will now reload the OperatingSystem plug-in. This was implemented by: - adding the ability to set a notify callback for when an option value is changed - added the ability for the process plug-in to load the operating system plug-in on the fly - fixed bugs in the Process::GetStatus() so all threads are displayed if their thread IDs are larger than 32 bits - adding a callback in ProcessProperties to tell when the "python-os-plugin-path" is changed by the user - fixing a crasher in ProcessMachCore that happens when updating the thread list when the OS plugin is reloaded llvm-svn: 225831
2015-01-14 05:13:08 +08:00
void
Process::LoadOperatingSystemPlugin(bool flush)
{
if (flush)
m_thread_list.Clear();
m_os_ap.reset (OperatingSystem::FindPlugin (this, NULL));
if (flush)
Flush();
}
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
Error
Expose SBPlatform through the public API. Example code: remote_platform = lldb.SBPlatform("remote-macosx"); remote_platform.SetWorkingDirectory("/private/tmp") debugger.SetSelectedPlatform(remote_platform) connect_options = lldb.SBPlatformConnectOptions("connect://localhost:1111"); err = remote_platform.ConnectRemote(connect_options) if err.Success(): print >> result, 'Connected to remote platform:' print >> result, 'hostname: %s' % (remote_platform.GetHostname()) src = lldb.SBFileSpec("/Applications/Xcode.app/Contents/SharedFrameworks/LLDB.framework", False) dst = lldb.SBFileSpec() # copy src to platform working directory since "dst" is empty err = remote_platform.Install(src, dst); if err.Success(): print >> result, '%s installed successfully' % (src) else: print >> result, 'error: failed to install "%s": %s' % (src, err) Implemented many calls needed in lldb-platform to be able to install a directory that contains symlinks, file and directories. The remote lldb-platform can now launch GDB servers on the remote system so that remote debugging can be spawned through the remote platform when connected to a remote platform. The API in SBPlatform is subject to change and will be getting many new functions. llvm-svn: 195273
2013-11-21 05:07:01 +08:00
Process::Launch (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();
Add support for JIT debugging on Linux using the GDB JIT interface. Patch written with Keno Fischer. llvm-svn: 202956
2014-03-05 18:12:43 +08:00
m_jit_loaders_ap.reset();
Add a new system runtime plugin type - just the top level class, not any actual plugin implementation yet. <rdar://problem/15314068> llvm-svn: 194044
2013-11-05 11:57:19 +08:00
m_system_runtime_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();
Handle thumb IT instructions correctly all the time. The issue with Thumb IT (if/then) instructions is the IT instruction preceeds up to four instructions that are made conditional. If a breakpoint is placed on one of the conditional instructions, the instruction either needs to match the thumb opcode size (2 or 4 bytes) or a BKPT instruction needs to be used as these are always unconditional (even in a IT instruction). If BKPT instructions are used, then we might end up stopping on an instruction that won't get executed. So if we do stop at a BKPT instruction, we need to continue if the condition is not true. When using the BKPT isntructions are easy in that you don't need to detect the size of the breakpoint that needs to be used when setting a breakpoint even in a thumb IT instruction. The bad part is you will now always stop at the opcode location and let LLDB determine if it should auto-continue. If the BKPT instruction is used, the BKPT that is used for ARM code should be something that also triggers the BKPT instruction in Thumb in case you set a breakpoint in the middle of code and the code is actually Thumb code. A value of 0xE120BE70 will work since the lower 16 bits being 0xBE70 happens to be a Thumb BKPT instruction. The alternative is to use trap or illegal instructions that the kernel will translate into breakpoint hits. On Mac this was 0xE7FFDEFE for ARM and 0xDEFE for Thumb. The darwin kernel currently doesn't recognize any 32 bit Thumb instruction as a instruction that will get turned into a breakpoint exception (EXC_BREAKPOINT), so we had to use the BKPT instruction on Mac. The linux kernel recognizes a 16 and a 32 bit instruction as valid thumb breakpoint opcodes. The benefit of using 16 or 32 bit instructions is you don't stop on opcodes in a IT block when the condition doesn't match. To further complicate things, single stepping on ARM is often implemented by modifying the BCR/BVR registers and setting the processor to stop when the PC is not equal to the current value. This means single stepping is another way the ARM target can stop on instructions that won't get executed. This patch does the following: 1 - Fix the internal debugserver for Apple to use the BKPT instruction for ARM and Thumb 2 - Fix LLDB to catch when we stop in the middle of a Thumb IT instruction and continue if we stop at an instruction that won't execute 3 - Fixes this in a way that will work for any target on any platform as long as it is ARM/Thumb 4 - Adds a patch for ignoring conditions that don't match when in ARM mode (see below) This patch also provides the code that implements the same thing for ARM instructions, though it is disabled for now. The ARM patch will check the condition of the instruction in ARM mode and continue if the condition isn't true (and therefore the instruction would not be executed). Again, this is not enable, but the code for it has been added. <rdar://problem/19145455> llvm-svn: 223851
2014-12-10 07:31:02 +08:00
m_stop_info_override_callback = NULL;
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
Have the Process hold a weak_ptr to the Target. llvm-svn: 246578
2015-09-02 04:02:29 +08:00
Module *exe_module = GetTarget().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())
{
Expose SBPlatform through the public API. Example code: remote_platform = lldb.SBPlatform("remote-macosx"); remote_platform.SetWorkingDirectory("/private/tmp") debugger.SetSelectedPlatform(remote_platform) connect_options = lldb.SBPlatformConnectOptions("connect://localhost:1111"); err = remote_platform.ConnectRemote(connect_options) if err.Success(): print >> result, 'Connected to remote platform:' print >> result, 'hostname: %s' % (remote_platform.GetHostname()) src = lldb.SBFileSpec("/Applications/Xcode.app/Contents/SharedFrameworks/LLDB.framework", False) dst = lldb.SBFileSpec() # copy src to platform working directory since "dst" is empty err = remote_platform.Install(src, dst); if err.Success(): print >> result, '%s installed successfully' % (src) else: print >> result, 'error: failed to install "%s": %s' % (src, err) Implemented many calls needed in lldb-platform to be able to install a directory that contains symlinks, file and directories. The remote lldb-platform can now launch GDB servers on the remote system so that remote debugging can be spawned through the remote platform when connected to a remote platform. The API in SBPlatform is subject to change and will be getting many new functions. llvm-svn: 195273
2013-11-21 05:07:01 +08:00
// Install anything that might need to be installed prior to launching.
// For host systems, this will do nothing, but if we are connected to a
// remote platform it will install any needed binaries
error = GetTarget().Install(&launch_info);
if (error.Fail())
return error;
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())
{
Figure out the reply to "PlanExplainsStop" once when we stop and then use the cached value. This fixes problems, for instance, with the StepRange plans, where they know that they explained the stop because they were at their "run to here" breakpoint, then deleted that breakpoint, so when they got asked again, doh! I had done this for a couple of plans in an ad hoc fashion, this just formalizes it. Also add a "ResumeRequested" in Process so that the code in the completion handlers can tell the ShouldStop logic they want to resume rather than just directly resuming. That allows us to handle resuming in a more controlled fashion. Also, SetPublicState can take a "restarted" flag, so that it doesn't drop the run lock when the target was immediately restarted. --This line, and those below , will be ignored-- M test/lang/objc/objc-dynamic-value/TestObjCDynamicValue.py M include/lldb/Target/ThreadList.h M include/lldb/Target/ThreadPlanStepOut.h M include/lldb/Target/Thread.h M include/lldb/Target/ThreadPlanBase.h M include/lldb/Target/ThreadPlanStepThrough.h M include/lldb/Target/ThreadPlanStepInstruction.h M include/lldb/Target/ThreadPlanStepInRange.h M include/lldb/Target/ThreadPlanStepOverBreakpoint.h M include/lldb/Target/ThreadPlanStepUntil.h M include/lldb/Target/StopInfo.h M include/lldb/Target/Process.h M include/lldb/Target/ThreadPlanRunToAddress.h M include/lldb/Target/ThreadPlan.h M include/lldb/Target/ThreadPlanCallFunction.h M include/lldb/Target/ThreadPlanStepOverRange.h M source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleThreadPlanStepThroughObjCTrampoline.h M source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleThreadPlanStepThroughObjCTrampoline.cpp M source/Target/StopInfo.cpp M source/Target/Process.cpp M source/Target/ThreadPlanRunToAddress.cpp M source/Target/ThreadPlan.cpp M source/Target/ThreadPlanCallFunction.cpp M source/Target/ThreadPlanStepOverRange.cpp M source/Target/ThreadList.cpp M source/Target/ThreadPlanStepOut.cpp M source/Target/Thread.cpp M source/Target/ThreadPlanBase.cpp M source/Target/ThreadPlanStepThrough.cpp M source/Target/ThreadPlanStepInstruction.cpp M source/Target/ThreadPlanStepInRange.cpp M source/Target/ThreadPlanStepOverBreakpoint.cpp M source/Target/ThreadPlanStepUntil.cpp M lldb.xcodeproj/xcshareddata/xcschemes/Run Testsuite.xcscheme llvm-svn: 181381
2013-05-08 08:35:16 +08:00
const bool restarted = false;
SetPublicState (eStateLaunching, restarted);
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
Use flag instead of rwlock state to track process running state LLDB requires that the inferior process be stopped before, and remain stopped during, certain accesses to process state. Previously this was achieved with a POSIX rwlock which had a write lock taken for the duration that the process was running, and released when the process was stopped. Any access to process state was performed with a read lock held. However, POSIX requires that pthread_rwlock_unlock() be called from the same thread as pthread_rwlock_wrlock(), and lldb needs to stop and start the process from different threads. Violating this constraint is technically undefined behaviour, although as it happens Linux and Darwin result in the unlock proceeding in this case. FreeBSD follows POSIX more strictly, and the unlock would fail, resulting in a hang later upon the next attempt to take the lock. All read lock consumers use ReadTryLock() and handle failure to obtain the lock (typically by logging an error "process is running"). Thus, instead of using the lock state itself to track the running state, this change adds an explicit m_running flag. ReadTryLock tests the flag, and if the process is not running it returns with the read lock held. WriteLock and WriteTryLock are renamed to SetRunning and TrySetRunning, and (if successful) they set m_running with the lock held. This way, read consumers can determine if the process is running and act appropriately, and write consumers are still held off from starting the process if read consumers are active. Note that with this change there are still some curious access patterns, such as calling WriteUnlock / SetStopped twice in a row, and there's no protection from multiple threads trying to simultaneously start the process. In practice this does not seem to be a problem, and was exposing other undefined POSIX behaviour prior to this change. llvm-svn: 187377
2013-07-30 04:58:06 +08:00
if (m_public_run_lock.TrySetRunning())
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
{
// 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.
Set error status when failed to catch stop after launch Process::Launch try to catch a stop signal after launching a process. If it is unsuccessful it destroy the process but previously still reported that the process launched successfully. This behavior caused a deadlock. With thic change the process launch error reported correctly. Differential revision: http://reviews.llvm.org/D7784 llvm-svn: 230212
2015-02-23 18:59:54 +08:00
error.SetErrorString ("failed to catch stop after launch");
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
SetExitStatus (0, "failed to catch stop after launch");
Add a "force_kill" arg to Process::Destroy(). This is needed after the changes in r233255/r233258. Normally if lldb attaches to a running process, when we call Process::Destroy, we want to detach from the process. If lldb launched the process itself, ::Destroy should kill it. However, if we attach to a process and the driver calls SBProcess::Kill() (which calls Destroy), we need to kill it even if we didn't launch it originally. The force_kill param allows for the SBProcess::Kill method to force the behavior of Destroy. <rdar://problem/20424439> llvm-svn: 235158
2015-04-17 13:01:58 +08:00
Destroy(false);
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
}
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
{
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
Create a Process::ModulesDidLoad() method to handle process-related tasks, as suggested by Jim Ingham. Make JITLoader instances use this to probe only new modules for relevant JIT symbols. Also re-enable the JITLoader hooks in Process. llvm-svn: 203774
2014-03-13 17:37:02 +08:00
GetJITLoaders().DidLaunch();
Add support for JIT debugging on Linux using the GDB JIT interface. Patch written with Keno Fischer. llvm-svn: 202956
2014-03-05 18:12:43 +08:00
Add a new system runtime plugin type - just the top level class, not any actual plugin implementation yet. <rdar://problem/15314068> llvm-svn: 194044
2013-11-05 11:57:19 +08:00
SystemRuntime *system_runtime = GetSystemRuntime ();
if (system_runtime)
system_runtime->DidLaunch();
Fixed an issue where if the operating system python plug-in is changed at runtime, it wouldn't cause the process to reload the new operating system plug-in, now it does. This is currently controlled by a setting: (lldb) settings set target.process.python-os-plugin-path <path> Or clearing it with: (lldb) settings clear target.process.python-os-plugin-path The process will now reload the OperatingSystem plug-in. This was implemented by: - adding the ability to set a notify callback for when an option value is changed - added the ability for the process plug-in to load the operating system plug-in on the fly - fixed bugs in the Process::GetStatus() so all threads are displayed if their thread IDs are larger than 32 bits - adding a callback in ProcessProperties to tell when the "python-os-plugin-path" is changed by the user - fixing a crasher in ProcessMachCore that happens when updating the thread list when the OS plugin is reloaded llvm-svn: 225831
2015-01-14 05:13:08 +08:00
LoadOperatingSystemPlugin(false);
Fix spurious output to command line when launching a process on Linux. See http://reviews.llvm.org/D5632 for details. Change by Shawn Best. llvm-svn: 219213
2014-10-08 00:05:21 +08:00
// Note, the stop event was consumed above, but not handled. This was done
// to give DidLaunch a chance to run. The target is either stopped or crashed.
// Directly set the state. This is done to prevent a stop message with a bunch
// of spurious output on thread status, as well as not pop a ProcessIOHandler.
SetPublicState(state, false);
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 ();
Handle thumb IT instructions correctly all the time. The issue with Thumb IT (if/then) instructions is the IT instruction preceeds up to four instructions that are made conditional. If a breakpoint is placed on one of the conditional instructions, the instruction either needs to match the thumb opcode size (2 or 4 bytes) or a BKPT instruction needs to be used as these are always unconditional (even in a IT instruction). If BKPT instructions are used, then we might end up stopping on an instruction that won't get executed. So if we do stop at a BKPT instruction, we need to continue if the condition is not true. When using the BKPT isntructions are easy in that you don't need to detect the size of the breakpoint that needs to be used when setting a breakpoint even in a thumb IT instruction. The bad part is you will now always stop at the opcode location and let LLDB determine if it should auto-continue. If the BKPT instruction is used, the BKPT that is used for ARM code should be something that also triggers the BKPT instruction in Thumb in case you set a breakpoint in the middle of code and the code is actually Thumb code. A value of 0xE120BE70 will work since the lower 16 bits being 0xBE70 happens to be a Thumb BKPT instruction. The alternative is to use trap or illegal instructions that the kernel will translate into breakpoint hits. On Mac this was 0xE7FFDEFE for ARM and 0xDEFE for Thumb. The darwin kernel currently doesn't recognize any 32 bit Thumb instruction as a instruction that will get turned into a breakpoint exception (EXC_BREAKPOINT), so we had to use the BKPT instruction on Mac. The linux kernel recognizes a 16 and a 32 bit instruction as valid thumb breakpoint opcodes. The benefit of using 16 or 32 bit instructions is you don't stop on opcodes in a IT block when the condition doesn't match. To further complicate things, single stepping on ARM is often implemented by modifying the BCR/BVR registers and setting the processor to stop when the PC is not equal to the current value. This means single stepping is another way the ARM target can stop on instructions that won't get executed. This patch does the following: 1 - Fix the internal debugserver for Apple to use the BKPT instruction for ARM and Thumb 2 - Fix LLDB to catch when we stop in the middle of a Thumb IT instruction and continue if we stop at an instruction that won't execute 3 - Fixes this in a way that will work for any target on any platform as long as it is ARM/Thumb 4 - Adds a patch for ignoring conditions that don't match when in ARM mode (see below) This patch also provides the code that implements the same thing for ARM instructions, though it is disabled for now. The ARM patch will check the condition of the instruction in ARM mode and continue if the condition isn't true (and therefore the instruction would not be executed). Again, this is not enable, but the code for it has been added. <rdar://problem/19145455> llvm-svn: 223851
2014-12-10 07:31:02 +08:00
m_stop_info_override_callback = GetTarget().GetArchitecture().GetStopInfoOverrideCallback();
Fix a missing "*stopped" notification in LLDB-MI after "process launch -s" in case of remote-macosx Summary: This patch fixes *stopped notification for remote target when started with eLaunchFlagStopAtEntry (for example, using "process launch -s"). See explanation below: ``` Target::Launch (ProcessLaunchInfo &launch_info, Stream *stream) { ... if (state != eStateConnected && platform_sp && platform_sp->CanDebugProcess ()) { ... } else { ... if (m_process_sp) error = m_process_sp->Launch (launch_info); } if (error.Success()) { if (launch_info.GetFlags().Test(eLaunchFlagStopAtEntry) == false) { .... } -- missing event if eLaunchFlagStopAtEntry is set -- m_process_sp->RestoreProcessEvents (); } ... return error ``` Also this patch contains tests and you can check how it works. Reviewers: zturner, clayborg, abidh Reviewed By: clayborg Subscribers: clayborg, abidh, zturner, lldb-commits Differential Revision: http://reviews.llvm.org/D7273 llvm-svn: 228417
2015-02-07 02:15:05 +08:00
// Target was stopped at entry as was intended. Need to notify the listeners
// about it.
Add extra check that target was stopped before the *stopped is sent. This patch fixes r228417. It's required because eStateCrushed case wasn't investigated. llvm-svn: 228824
2015-02-11 19:24:20 +08:00
if (state == eStateStopped && launch_info.GetFlags().Test(eLaunchFlagStopAtEntry))
Fix a missing "*stopped" notification in LLDB-MI after "process launch -s" in case of remote-macosx Summary: This patch fixes *stopped notification for remote target when started with eLaunchFlagStopAtEntry (for example, using "process launch -s"). See explanation below: ``` Target::Launch (ProcessLaunchInfo &launch_info, Stream *stream) { ... if (state != eStateConnected && platform_sp && platform_sp->CanDebugProcess ()) { ... } else { ... if (m_process_sp) error = m_process_sp->Launch (launch_info); } if (error.Success()) { if (launch_info.GetFlags().Test(eLaunchFlagStopAtEntry) == false) { .... } -- missing event if eLaunchFlagStopAtEntry is set -- m_process_sp->RestoreProcessEvents (); } ... return error ``` Also this patch contains tests and you can check how it works. Reviewers: zturner, clayborg, abidh Reviewed By: clayborg Subscribers: clayborg, abidh, zturner, lldb-commits Differential Revision: http://reviews.llvm.org/D7273 llvm-svn: 228417
2015-02-07 02:15:05 +08:00
HandlePrivateEvent(event_sp);
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())
{
Avoid a race condition when loading core files where the process might still be handling the eStateStopped event we post to the private state thread causing us to return from SBTarget::LoadCore() before the process is ready to have API calls used on it. This fixes a crasher that could happen when loading core files from scripts. llvm-svn: 230060
2015-02-21 04:59:47 +08:00
Listener listener ("lldb.process.load_core_listener");
Make sure the public state is eStateStopped when we return from SBTarget::LoadCore() by hijacking the public event queue so we can ensure that the event gets consumed and the public state of the process (StateType SBProcess::GetState()) returns eStateStopped. llvm-svn: 230066
2015-02-21 05:51:06 +08:00
HijackProcessEvents(&listener);
Avoid a race condition when loading core files where the process might still be handling the eStateStopped event we post to the private state thread causing us to return from SBTarget::LoadCore() before the process is ready to have API calls used on it. This fixes a crasher that could happen when loading core files from scripts. llvm-svn: 230060
2015-02-21 04:59:47 +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
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();
Add support for JIT debugging on Linux using the GDB JIT interface. Patch written with Keno Fischer. llvm-svn: 202956
2014-03-05 18:12:43 +08:00
Create a Process::ModulesDidLoad() method to handle process-related tasks, as suggested by Jim Ingham. Make JITLoader instances use this to probe only new modules for relevant JIT symbols. Also re-enable the JITLoader hooks in Process. llvm-svn: 203774
2014-03-13 17:37:02 +08:00
GetJITLoaders().DidAttach();
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
Add a new system runtime plugin type - just the top level class, not any actual plugin implementation yet. <rdar://problem/15314068> llvm-svn: 194044
2013-11-05 11:57:19 +08:00
SystemRuntime *system_runtime = GetSystemRuntime ();
if (system_runtime)
system_runtime->DidAttach();
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
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);
Avoid a race condition when loading core files where the process might still be handling the eStateStopped event we post to the private state thread causing us to return from SBTarget::LoadCore() before the process is ready to have API calls used on it. This fixes a crasher that could happen when loading core files from scripts. llvm-svn: 230060
2015-02-21 04:59:47 +08:00
// Wait indefinitely for a stopped event since we just posted one above...
lldb::EventSP event_sp;
listener.WaitForEvent (NULL, event_sp);
StateType state = ProcessEventData::GetStateFromEvent(event_sp.get());
if (!StateIsStoppedState (state, false))
{
Log *log(lldb_private::GetLogIfAllCategoriesSet (LIBLLDB_LOG_PROCESS));
if (log)
log->Printf("Process::Halt() failed to stop, state is: %s", StateAsCString(state));
error.SetErrorString ("Did not get stopped event after loading the core file.");
}
Make sure the public state is eStateStopped when we return from SBTarget::LoadCore() by hijacking the public event queue so we can ensure that the event gets consumed and the public state of the process (StateType SBProcess::GetState()) returns eStateStopped. llvm-svn: 230066
2015-02-21 05:51:06 +08:00
RestoreProcessEvents ();
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 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
Add lldb-gdbserver support for Linux x86_64. This change brings in lldb-gdbserver (llgs) specifically for Linux x86_64. (More architectures coming soon). Not every debugserver option is covered yet. Currently the lldb-gdbserver command line can start unattached, start attached to a pid (process-name attach not supported yet), or accept lldb attaching and launching a process or connecting by process id. The history of this large change can be found here: https://github.com/tfiala/lldb/tree/dev-tfiala-native-protocol-linux-x86_64 Until mid/late April, I was not sharing the work and continued to rebase it off of head (developed via id tfiala@google.com). I switched over to user todd.fiala@gmail.com in the middle, and once I went to github, I did merges rather than rebasing so I could share with others. llvm-svn: 212069
2014-07-01 05:05:18 +08:00
const lldb::DataBufferSP
Process::GetAuxvData()
{
return DataBufferSP ();
}
Add support for JIT debugging on Linux using the GDB JIT interface. Patch written with Keno Fischer. llvm-svn: 202956
2014-03-05 18:12:43 +08:00
JITLoaderList &
Process::GetJITLoaders ()
{
if (!m_jit_loaders_ap)
{
m_jit_loaders_ap.reset(new JITLoaderList());
JITLoader::LoadPlugins(this, *m_jit_loaders_ap);
}
return *m_jit_loaders_ap;
}
Add a new system runtime plugin type - just the top level class, not any actual plugin implementation yet. <rdar://problem/15314068> llvm-svn: 194044
2013-11-05 11:57:19 +08:00
SystemRuntime *
Process::GetSystemRuntime ()
{
if (m_system_runtime_ap.get() == NULL)
m_system_runtime_ap.reset (SystemRuntime::FindPlugin(this));
return m_system_runtime_ap.get();
}
Add some logging around Process attaching and inferior exec handling. llvm-svn: 216630
2014-08-28 06:58:26 +08:00
Process::AttachCompletionHandler::AttachCompletionHandler (Process *process, uint32_t exec_count) :
NextEventAction (process),
m_exec_count (exec_count)
{
Log *log(lldb_private::GetLogIfAllCategoriesSet (LIBLLDB_LOG_PROCESS));
if (log)
log->Printf ("Process::AttachCompletionHandler::%s process=%p, exec_count=%" PRIu32, __FUNCTION__, static_cast<void*>(process), exec_count);
}
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
{
Add some logging around Process attaching and inferior exec handling. llvm-svn: 216630
2014-08-28 06:58:26 +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
StateType state = ProcessEventData::GetStateFromEvent (event_sp.get());
Add some logging around Process attaching and inferior exec handling. llvm-svn: 216630
2014-08-28 06:58:26 +08:00
if (log)
log->Printf ("Process::AttachCompletionHandler::%s called with state %s (%d)", __FUNCTION__, StateAsCString(state), static_cast<int> (state));
switch (state)
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
{
Implement attach to process on Windows. Differential Revision: http://reviews.llvm.org/D9801 Reviewed by: Adrian McCarthy llvm-svn: 237817
2015-05-21 02:31:17 +08:00
case eStateAttaching:
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
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);
Figure out the reply to "PlanExplainsStop" once when we stop and then use the cached value. This fixes problems, for instance, with the StepRange plans, where they know that they explained the stop because they were at their "run to here" breakpoint, then deleted that breakpoint, so when they got asked again, doh! I had done this for a couple of plans in an ad hoc fashion, this just formalizes it. Also add a "ResumeRequested" in Process so that the code in the completion handlers can tell the ShouldStop logic they want to resume rather than just directly resuming. That allows us to handle resuming in a more controlled fashion. Also, SetPublicState can take a "restarted" flag, so that it doesn't drop the run lock when the target was immediately restarted. --This line, and those below , will be ignored-- M test/lang/objc/objc-dynamic-value/TestObjCDynamicValue.py M include/lldb/Target/ThreadList.h M include/lldb/Target/ThreadPlanStepOut.h M include/lldb/Target/Thread.h M include/lldb/Target/ThreadPlanBase.h M include/lldb/Target/ThreadPlanStepThrough.h M include/lldb/Target/ThreadPlanStepInstruction.h M include/lldb/Target/ThreadPlanStepInRange.h M include/lldb/Target/ThreadPlanStepOverBreakpoint.h M include/lldb/Target/ThreadPlanStepUntil.h M include/lldb/Target/StopInfo.h M include/lldb/Target/Process.h M include/lldb/Target/ThreadPlanRunToAddress.h M include/lldb/Target/ThreadPlan.h M include/lldb/Target/ThreadPlanCallFunction.h M include/lldb/Target/ThreadPlanStepOverRange.h M source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleThreadPlanStepThroughObjCTrampoline.h M source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleThreadPlanStepThroughObjCTrampoline.cpp M source/Target/StopInfo.cpp M source/Target/Process.cpp M source/Target/ThreadPlanRunToAddress.cpp M source/Target/ThreadPlan.cpp M source/Target/ThreadPlanCallFunction.cpp M source/Target/ThreadPlanStepOverRange.cpp M source/Target/ThreadList.cpp M source/Target/ThreadPlanStepOut.cpp M source/Target/Thread.cpp M source/Target/ThreadPlanBase.cpp M source/Target/ThreadPlanStepThrough.cpp M source/Target/ThreadPlanStepInstruction.cpp M source/Target/ThreadPlanStepInRange.cpp M source/Target/ThreadPlanStepOverBreakpoint.cpp M source/Target/ThreadPlanStepUntil.cpp M lldb.xcodeproj/xcshareddata/xcschemes/Run Testsuite.xcscheme llvm-svn: 181381
2013-05-08 08:35:16 +08:00
// We don't want these events to be reported, so go set the ShouldReportStop here:
m_process->GetThreadList().SetShouldReportStop (eVoteNo);
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
if (m_exec_count > 0)
{
--m_exec_count;
Add some logging around Process attaching and inferior exec handling. llvm-svn: 216630
2014-08-28 06:58:26 +08:00
if (log)
log->Printf ("Process::AttachCompletionHandler::%s state %s: reduced remaining exec count to %" PRIu32 ", requesting resume", __FUNCTION__, StateAsCString(state), m_exec_count);
Figure out the reply to "PlanExplainsStop" once when we stop and then use the cached value. This fixes problems, for instance, with the StepRange plans, where they know that they explained the stop because they were at their "run to here" breakpoint, then deleted that breakpoint, so when they got asked again, doh! I had done this for a couple of plans in an ad hoc fashion, this just formalizes it. Also add a "ResumeRequested" in Process so that the code in the completion handlers can tell the ShouldStop logic they want to resume rather than just directly resuming. That allows us to handle resuming in a more controlled fashion. Also, SetPublicState can take a "restarted" flag, so that it doesn't drop the run lock when the target was immediately restarted. --This line, and those below , will be ignored-- M test/lang/objc/objc-dynamic-value/TestObjCDynamicValue.py M include/lldb/Target/ThreadList.h M include/lldb/Target/ThreadPlanStepOut.h M include/lldb/Target/Thread.h M include/lldb/Target/ThreadPlanBase.h M include/lldb/Target/ThreadPlanStepThrough.h M include/lldb/Target/ThreadPlanStepInstruction.h M include/lldb/Target/ThreadPlanStepInRange.h M include/lldb/Target/ThreadPlanStepOverBreakpoint.h M include/lldb/Target/ThreadPlanStepUntil.h M include/lldb/Target/StopInfo.h M include/lldb/Target/Process.h M include/lldb/Target/ThreadPlanRunToAddress.h M include/lldb/Target/ThreadPlan.h M include/lldb/Target/ThreadPlanCallFunction.h M include/lldb/Target/ThreadPlanStepOverRange.h M source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleThreadPlanStepThroughObjCTrampoline.h M source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleThreadPlanStepThroughObjCTrampoline.cpp M source/Target/StopInfo.cpp M source/Target/Process.cpp M source/Target/ThreadPlanRunToAddress.cpp M source/Target/ThreadPlan.cpp M source/Target/ThreadPlanCallFunction.cpp M source/Target/ThreadPlanStepOverRange.cpp M source/Target/ThreadList.cpp M source/Target/ThreadPlanStepOut.cpp M source/Target/Thread.cpp M source/Target/ThreadPlanBase.cpp M source/Target/ThreadPlanStepThrough.cpp M source/Target/ThreadPlanStepInstruction.cpp M source/Target/ThreadPlanStepInRange.cpp M source/Target/ThreadPlanStepOverBreakpoint.cpp M source/Target/ThreadPlanStepUntil.cpp M lldb.xcodeproj/xcshareddata/xcschemes/Run Testsuite.xcscheme llvm-svn: 181381
2013-05-08 08:35:16 +08:00
RequestResume();
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
{
Add some logging around Process attaching and inferior exec handling. llvm-svn: 216630
2014-08-28 06:58:26 +08:00
if (log)
log->Printf ("Process::AttachCompletionHandler::%s state %s: no more execs expected to start, continuing with attach", __FUNCTION__, StateAsCString(state));
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_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
}
Fixed more fallout from running the test suite remotely on iOS devices. Fixed include: - Change Platform::ResolveExecutable(...) to take a ModuleSpec instead of a FileSpec + ArchSpec to help resolve executables correctly when we have just a path + UUID (no arch). - Add the ability to set the listener in SBLaunchInfo and SBAttachInfo in case you don't want to use the debugger as the default listener. - Modified all places that use the SBLaunchInfo/SBAttachInfo and the internal ProcessLaunchInfo/ProcessAttachInfo to not take a listener as a parameter since it is in the launch/attach info now - Load a module's sections by default when removing a module from a target. Since we create JIT modules for expressions and helper functions, we could end up with stale data in the section load list if a module was removed from the target as the section load list would still have entries for the unloaded module. Target now has the following functions to help unload all sections a single or multiple modules: size_t Target::UnloadModuleSections (const ModuleList &module_list); size_t Target::UnloadModuleSections (const lldb::ModuleSP &module_sp); llvm-svn: 222167
2014-11-18 03:39:20 +08:00
Listener &
ProcessAttachInfo::GetListenerForProcess (Debugger &debugger)
{
if (m_listener_sp)
return *m_listener_sp;
else
return debugger.GetListener();
}
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();
Add support for JIT debugging on Linux using the GDB JIT interface. Patch written with Keno Fischer. llvm-svn: 202956
2014-03-05 18:12:43 +08:00
m_jit_loaders_ap.reset();
Add a new system runtime plugin type - just the top level class, not any actual plugin implementation yet. <rdar://problem/15314068> llvm-svn: 194044
2013-11-05 11:57:19 +08:00
m_system_runtime_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();
Handle thumb IT instructions correctly all the time. The issue with Thumb IT (if/then) instructions is the IT instruction preceeds up to four instructions that are made conditional. If a breakpoint is placed on one of the conditional instructions, the instruction either needs to match the thumb opcode size (2 or 4 bytes) or a BKPT instruction needs to be used as these are always unconditional (even in a IT instruction). If BKPT instructions are used, then we might end up stopping on an instruction that won't get executed. So if we do stop at a BKPT instruction, we need to continue if the condition is not true. When using the BKPT isntructions are easy in that you don't need to detect the size of the breakpoint that needs to be used when setting a breakpoint even in a thumb IT instruction. The bad part is you will now always stop at the opcode location and let LLDB determine if it should auto-continue. If the BKPT instruction is used, the BKPT that is used for ARM code should be something that also triggers the BKPT instruction in Thumb in case you set a breakpoint in the middle of code and the code is actually Thumb code. A value of 0xE120BE70 will work since the lower 16 bits being 0xBE70 happens to be a Thumb BKPT instruction. The alternative is to use trap or illegal instructions that the kernel will translate into breakpoint hits. On Mac this was 0xE7FFDEFE for ARM and 0xDEFE for Thumb. The darwin kernel currently doesn't recognize any 32 bit Thumb instruction as a instruction that will get turned into a breakpoint exception (EXC_BREAKPOINT), so we had to use the BKPT instruction on Mac. The linux kernel recognizes a 16 and a 32 bit instruction as valid thumb breakpoint opcodes. The benefit of using 16 or 32 bit instructions is you don't stop on opcodes in a IT block when the condition doesn't match. To further complicate things, single stepping on ARM is often implemented by modifying the BCR/BVR registers and setting the processor to stop when the PC is not equal to the current value. This means single stepping is another way the ARM target can stop on instructions that won't get executed. This patch does the following: 1 - Fix the internal debugserver for Apple to use the BKPT instruction for ARM and Thumb 2 - Fix LLDB to catch when we stop in the middle of a Thumb IT instruction and continue if we stop at an instruction that won't execute 3 - Fixes this in a way that will work for any target on any platform as long as it is ARM/Thumb 4 - Adds a patch for ignoring conditions that don't match when in ARM mode (see below) This patch also provides the code that implements the same thing for ARM instructions, though it is disabled for now. The ARM patch will check the condition of the instruction in ARM mode and continue if the condition isn't true (and therefore the instruction would not be executed). Again, this is not enable, but the code for it has been added. <rdar://problem/19145455> llvm-svn: 223851
2014-12-10 07:31:02 +08:00
m_stop_info_override_callback = NULL;
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())
{
Use flag instead of rwlock state to track process running state LLDB requires that the inferior process be stopped before, and remain stopped during, certain accesses to process state. Previously this was achieved with a POSIX rwlock which had a write lock taken for the duration that the process was running, and released when the process was stopped. Any access to process state was performed with a read lock held. However, POSIX requires that pthread_rwlock_unlock() be called from the same thread as pthread_rwlock_wrlock(), and lldb needs to stop and start the process from different threads. Violating this constraint is technically undefined behaviour, although as it happens Linux and Darwin result in the unlock proceeding in this case. FreeBSD follows POSIX more strictly, and the unlock would fail, resulting in a hang later upon the next attempt to take the lock. All read lock consumers use ReadTryLock() and handle failure to obtain the lock (typically by logging an error "process is running"). Thus, instead of using the lock state itself to track the running state, this change adds an explicit m_running flag. ReadTryLock tests the flag, and if the process is not running it returns with the read lock held. WriteLock and WriteTryLock are renamed to SetRunning and TrySetRunning, and (if successful) they set m_running with the lock held. This way, read consumers can determine if the process is running and act appropriately, and write consumers are still held off from starting the process if read consumers are active. Note that with this change there are still some curious access patterns, such as calling WriteUnlock / SetStopped twice in a row, and there's no protection from multiple threads trying to simultaneously start the process. In practice this does not seem to be a problem, and was exposing other undefined POSIX behaviour prior to this change. llvm-svn: 187377
2013-07-30 04:58:06 +08:00
if (m_public_run_lock.TrySetRunning())
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
{
m_should_detach = true;
Figure out the reply to "PlanExplainsStop" once when we stop and then use the cached value. This fixes problems, for instance, with the StepRange plans, where they know that they explained the stop because they were at their "run to here" breakpoint, then deleted that breakpoint, so when they got asked again, doh! I had done this for a couple of plans in an ad hoc fashion, this just formalizes it. Also add a "ResumeRequested" in Process so that the code in the completion handlers can tell the ShouldStop logic they want to resume rather than just directly resuming. That allows us to handle resuming in a more controlled fashion. Also, SetPublicState can take a "restarted" flag, so that it doesn't drop the run lock when the target was immediately restarted. --This line, and those below , will be ignored-- M test/lang/objc/objc-dynamic-value/TestObjCDynamicValue.py M include/lldb/Target/ThreadList.h M include/lldb/Target/ThreadPlanStepOut.h M include/lldb/Target/Thread.h M include/lldb/Target/ThreadPlanBase.h M include/lldb/Target/ThreadPlanStepThrough.h M include/lldb/Target/ThreadPlanStepInstruction.h M include/lldb/Target/ThreadPlanStepInRange.h M include/lldb/Target/ThreadPlanStepOverBreakpoint.h M include/lldb/Target/ThreadPlanStepUntil.h M include/lldb/Target/StopInfo.h M include/lldb/Target/Process.h M include/lldb/Target/ThreadPlanRunToAddress.h M include/lldb/Target/ThreadPlan.h M include/lldb/Target/ThreadPlanCallFunction.h M include/lldb/Target/ThreadPlanStepOverRange.h M source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleThreadPlanStepThroughObjCTrampoline.h M source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleThreadPlanStepThroughObjCTrampoline.cpp M source/Target/StopInfo.cpp M source/Target/Process.cpp M source/Target/ThreadPlanRunToAddress.cpp M source/Target/ThreadPlan.cpp M source/Target/ThreadPlanCallFunction.cpp M source/Target/ThreadPlanStepOverRange.cpp M source/Target/ThreadList.cpp M source/Target/ThreadPlanStepOut.cpp M source/Target/Thread.cpp M source/Target/ThreadPlanBase.cpp M source/Target/ThreadPlanStepThrough.cpp M source/Target/ThreadPlanStepInstruction.cpp M source/Target/ThreadPlanStepInRange.cpp M source/Target/ThreadPlanStepOverBreakpoint.cpp M source/Target/ThreadPlanStepUntil.cpp M lldb.xcodeproj/xcshareddata/xcschemes/Run Testsuite.xcscheme llvm-svn: 181381
2013-05-08 08:35:16 +08:00
const bool restarted = false;
SetPublicState (eStateAttaching, restarted);
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
// Now attach using these arguments.
Remove wait_for_launch parameter from DoAttachToProcessWithName(). This parameter is redundant as this information is already provided by the ProcessAttachInfo parameter. CC: lldb-commits Differential Revision: http://llvm-reviews.chandlerc.com/D2463 llvm-svn: 197923
2013-12-24 06:32:54 +08:00
error = DoAttachToProcessWithName (process_name, attach_info);
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
}
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;
Have the Process hold a weak_ptr to the Target. llvm-svn: 246578
2015-09-02 04:02:29 +08:00
PlatformSP platform_sp (GetTarget().GetPlatform ());
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 (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)
Fix a thinko in the process list formatting. Made Process::Attach list the matching processes if there is more than one match. <rdar://problem/18023352> llvm-svn: 215730
2014-08-16 01:05:27 +08:00
{
StreamString s;
ProcessInstanceInfo::DumpTableHeader (s, platform_sp.get(), true, false);
for (size_t i = 0; i < num_matches; i++)
{
process_infos.GetProcessInfoAtIndex(i).DumpAsTableRow(s, platform_sp.get(), true, false);
}
error.SetErrorStringWithFormat ("more than one process named %s:\n%s",
process_name,
s.GetData());
}
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
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
Use flag instead of rwlock state to track process running state LLDB requires that the inferior process be stopped before, and remain stopped during, certain accesses to process state. Previously this was achieved with a POSIX rwlock which had a write lock taken for the duration that the process was running, and released when the process was stopped. Any access to process state was performed with a read lock held. However, POSIX requires that pthread_rwlock_unlock() be called from the same thread as pthread_rwlock_wrlock(), and lldb needs to stop and start the process from different threads. Violating this constraint is technically undefined behaviour, although as it happens Linux and Darwin result in the unlock proceeding in this case. FreeBSD follows POSIX more strictly, and the unlock would fail, resulting in a hang later upon the next attempt to take the lock. All read lock consumers use ReadTryLock() and handle failure to obtain the lock (typically by logging an error "process is running"). Thus, instead of using the lock state itself to track the running state, this change adds an explicit m_running flag. ReadTryLock tests the flag, and if the process is not running it returns with the read lock held. WriteLock and WriteTryLock are renamed to SetRunning and TrySetRunning, and (if successful) they set m_running with the lock held. This way, read consumers can determine if the process is running and act appropriately, and write consumers are still held off from starting the process if read consumers are active. Note that with this change there are still some curious access patterns, such as calling WriteUnlock / SetStopped twice in a row, and there's no protection from multiple threads trying to simultaneously start the process. In practice this does not seem to be a problem, and was exposing other undefined POSIX behaviour prior to this change. llvm-svn: 187377
2013-07-30 04:58:06 +08:00
if (m_public_run_lock.TrySetRunning())
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
{
// Now attach using these arguments.
m_should_detach = true;
Figure out the reply to "PlanExplainsStop" once when we stop and then use the cached value. This fixes problems, for instance, with the StepRange plans, where they know that they explained the stop because they were at their "run to here" breakpoint, then deleted that breakpoint, so when they got asked again, doh! I had done this for a couple of plans in an ad hoc fashion, this just formalizes it. Also add a "ResumeRequested" in Process so that the code in the completion handlers can tell the ShouldStop logic they want to resume rather than just directly resuming. That allows us to handle resuming in a more controlled fashion. Also, SetPublicState can take a "restarted" flag, so that it doesn't drop the run lock when the target was immediately restarted. --This line, and those below , will be ignored-- M test/lang/objc/objc-dynamic-value/TestObjCDynamicValue.py M include/lldb/Target/ThreadList.h M include/lldb/Target/ThreadPlanStepOut.h M include/lldb/Target/Thread.h M include/lldb/Target/ThreadPlanBase.h M include/lldb/Target/ThreadPlanStepThrough.h M include/lldb/Target/ThreadPlanStepInstruction.h M include/lldb/Target/ThreadPlanStepInRange.h M include/lldb/Target/ThreadPlanStepOverBreakpoint.h M include/lldb/Target/ThreadPlanStepUntil.h M include/lldb/Target/StopInfo.h M include/lldb/Target/Process.h M include/lldb/Target/ThreadPlanRunToAddress.h M include/lldb/Target/ThreadPlan.h M include/lldb/Target/ThreadPlanCallFunction.h M include/lldb/Target/ThreadPlanStepOverRange.h M source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleThreadPlanStepThroughObjCTrampoline.h M source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleThreadPlanStepThroughObjCTrampoline.cpp M source/Target/StopInfo.cpp M source/Target/Process.cpp M source/Target/ThreadPlanRunToAddress.cpp M source/Target/ThreadPlan.cpp M source/Target/ThreadPlanCallFunction.cpp M source/Target/ThreadPlanStepOverRange.cpp M source/Target/ThreadList.cpp M source/Target/ThreadPlanStepOut.cpp M source/Target/Thread.cpp M source/Target/ThreadPlanBase.cpp M source/Target/ThreadPlanStepThrough.cpp M source/Target/ThreadPlanStepInstruction.cpp M source/Target/ThreadPlanStepInRange.cpp M source/Target/ThreadPlanStepOverBreakpoint.cpp M source/Target/ThreadPlanStepUntil.cpp M lldb.xcodeproj/xcshareddata/xcschemes/Run Testsuite.xcscheme llvm-svn: 181381
2013-05-08 08:35:16 +08:00
const bool restarted = false;
SetPublicState (eStateAttaching, restarted);
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
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);
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
Add test for denied process attach by pid and fix found bugs in Process/ProcessPOSIX.cpp and FreeBSD/ProcessMonitor. http://reviews.llvm.org/D6240 llvm-svn: 222372
2014-11-20 02:27:45 +08:00
const char *error_string = error.AsCString();
if (error_string == NULL)
error_string = "attach failed";
SetExitStatus(-1, error_string);
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
}
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 ()
{
Add some logging around Process attaching and inferior exec handling. llvm-svn: 216630
2014-08-28 06:58:26 +08:00
Log *log(lldb_private::GetLogIfAllCategoriesSet (LIBLLDB_LOG_PROCESS));
if (log)
log->Printf ("Process::%s()", __FUNCTION__);
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
// Let the process subclass figure out at much as it can about the process
// before we go looking for a dynamic loader plug-in.
After you attach, give the process plugin a chance to report back (through DidAttach) the architecture of the binary you attached to. <rdar://problem/17891396> llvm-svn: 214603
2014-08-02 08:33:35 +08:00
ArchSpec process_arch;
DidAttach(process_arch);
if (process_arch.IsValid())
Add some logging around Process attaching and inferior exec handling. llvm-svn: 216630
2014-08-28 06:58:26 +08:00
{
Have the Process hold a weak_ptr to the Target. llvm-svn: 246578
2015-09-02 04:02:29 +08:00
GetTarget().SetArchitecture(process_arch);
Add some logging around Process attaching and inferior exec handling. llvm-svn: 216630
2014-08-28 06:58:26 +08:00
if (log)
{
const char *triple_str = process_arch.GetTriple().getTriple().c_str ();
log->Printf ("Process::%s replacing process architecture with DidAttach() architecture: %s",
__FUNCTION__,
triple_str ? triple_str : "<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
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.
Have the Process hold a weak_ptr to the Target. llvm-svn: 246578
2015-09-02 04:02:29 +08:00
PlatformSP platform_sp (GetTarget().GetPlatform ());
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
assert (platform_sp.get());
if (platform_sp)
{
Have the Process hold a weak_ptr to the Target. llvm-svn: 246578
2015-09-02 04:02:29 +08:00
const ArchSpec &target_arch = GetTarget().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)
{
Have the Process hold a weak_ptr to the Target. llvm-svn: 246578
2015-09-02 04:02:29 +08:00
GetTarget().SetPlatform (platform_sp);
GetTarget().SetArchitecture(platform_arch);
Add some logging around Process attaching and inferior exec handling. llvm-svn: 216630
2014-08-28 06:58:26 +08:00
if (log)
log->Printf ("Process::%s switching platform to %s and architecture to %s based on info from attach", __FUNCTION__, platform_sp->GetName().AsCString (""), platform_arch.GetTriple().getTriple().c_str ());
<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
}
}
After you attach, give the process plugin a chance to report back (through DidAttach) the architecture of the binary you attached to. <rdar://problem/17891396> llvm-svn: 214603
2014-08-02 08:33:35 +08:00
else if (!process_arch.IsValid())
<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
{
ProcessInstanceInfo process_info;
platform_sp->GetProcessInfo (GetID(), process_info);
const ArchSpec &process_arch = process_info.GetArchitecture();
Have the Process hold a weak_ptr to the Target. llvm-svn: 246578
2015-09-02 04:02:29 +08:00
if (process_arch.IsValid() && !GetTarget().GetArchitecture().IsExactMatch(process_arch))
Add some logging around Process attaching and inferior exec handling. llvm-svn: 216630
2014-08-28 06:58:26 +08:00
{
Have the Process hold a weak_ptr to the Target. llvm-svn: 246578
2015-09-02 04:02:29 +08:00
GetTarget().SetArchitecture (process_arch);
Add some logging around Process attaching and inferior exec handling. llvm-svn: 216630
2014-08-28 06:58:26 +08:00
if (log)
log->Printf ("Process::%s switching architecture to %s based on info the platform retrieved for pid %" PRIu64, __FUNCTION__, process_arch.GetTriple().getTriple().c_str (), GetID ());
}
<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
}
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)
Add some logging around Process attaching and inferior exec handling. llvm-svn: 216630
2014-08-28 06:58:26 +08:00
{
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
dyld->DidAttach();
Add some logging around Process attaching and inferior exec handling. llvm-svn: 216630
2014-08-28 06:58:26 +08:00
if (log)
{
Have the Process hold a weak_ptr to the Target. llvm-svn: 246578
2015-09-02 04:02:29 +08:00
ModuleSP exe_module_sp = GetTarget().GetExecutableModule ();
Add some logging around Process attaching and inferior exec handling. llvm-svn: 216630
2014-08-28 06:58:26 +08:00
log->Printf ("Process::%s after DynamicLoader::DidAttach(), target executable is %s (using %s plugin)",
__FUNCTION__,
exe_module_sp ? exe_module_sp->GetFileSpec().GetPath().c_str () : "<none>",
dyld->GetPluginName().AsCString ("<unnamed>"));
}
}
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
Create a Process::ModulesDidLoad() method to handle process-related tasks, as suggested by Jim Ingham. Make JITLoader instances use this to probe only new modules for relevant JIT symbols. Also re-enable the JITLoader hooks in Process. llvm-svn: 203774
2014-03-13 17:37:02 +08:00
GetJITLoaders().DidAttach();
Add support for JIT debugging on Linux using the GDB JIT interface. Patch written with Keno Fischer. llvm-svn: 202956
2014-03-05 18:12:43 +08:00
Add a new system runtime plugin type - just the top level class, not any actual plugin implementation yet. <rdar://problem/15314068> llvm-svn: 194044
2013-11-05 11:57:19 +08:00
SystemRuntime *system_runtime = GetSystemRuntime ();
if (system_runtime)
Add some logging around Process attaching and inferior exec handling. llvm-svn: 216630
2014-08-28 06:58:26 +08:00
{
Add a new system runtime plugin type - just the top level class, not any actual plugin implementation yet. <rdar://problem/15314068> llvm-svn: 194044
2013-11-05 11:57:19 +08:00
system_runtime->DidAttach();
Add some logging around Process attaching and inferior exec handling. llvm-svn: 216630
2014-08-28 06:58:26 +08:00
if (log)
{
Have the Process hold a weak_ptr to the Target. llvm-svn: 246578
2015-09-02 04:02:29 +08:00
ModuleSP exe_module_sp = GetTarget().GetExecutableModule ();
Add some logging around Process attaching and inferior exec handling. llvm-svn: 216630
2014-08-28 06:58:26 +08:00
log->Printf ("Process::%s after SystemRuntime::DidAttach(), target executable is %s (using %s plugin)",
__FUNCTION__,
exe_module_sp ? exe_module_sp->GetFileSpec().GetPath().c_str () : "<none>",
system_runtime->GetPluginName().AsCString("<unnamed>"));
}
}
Add a new system runtime plugin type - just the top level class, not any actual plugin implementation yet. <rdar://problem/15314068> llvm-svn: 194044
2013-11-05 11:57:19 +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:
Have the Process hold a weak_ptr to the Target. llvm-svn: 246578
2015-09-02 04:02:29 +08:00
const ModuleList &target_modules = GetTarget().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
Sort out a number of mismatched integer types in order to cut down the number of compiler warnings. llvm-svn: 184333
2013-06-20 03:04:53 +08:00
for (size_t i = 0; i < num_modules; i++)
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
{
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
{
Have the Process hold a weak_ptr to the Target. llvm-svn: 246578
2015-09-02 04:02:29 +08:00
if (GetTarget().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)
Add some logging around Process attaching and inferior exec handling. llvm-svn: 216630
2014-08-28 06:58:26 +08:00
{
Have the Process hold a weak_ptr to the Target. llvm-svn: 246578
2015-09-02 04:02:29 +08:00
GetTarget().SetExecutableModule (new_executable_module_sp, false);
Add some logging around Process attaching and inferior exec handling. llvm-svn: 216630
2014-08-28 06:58:26 +08:00
if (log)
{
Have the Process hold a weak_ptr to the Target. llvm-svn: 246578
2015-09-02 04:02:29 +08:00
ModuleSP exe_module_sp = GetTarget().GetExecutableModule ();
Add some logging around Process attaching and inferior exec handling. llvm-svn: 216630
2014-08-28 06:58:26 +08:00
log->Printf ("Process::%s after looping through modules, target executable is %s",
__FUNCTION__,
exe_module_sp ? exe_module_sp->GetFileSpec().GetPath().c_str () : "<none>");
}
}
Handle thumb IT instructions correctly all the time. The issue with Thumb IT (if/then) instructions is the IT instruction preceeds up to four instructions that are made conditional. If a breakpoint is placed on one of the conditional instructions, the instruction either needs to match the thumb opcode size (2 or 4 bytes) or a BKPT instruction needs to be used as these are always unconditional (even in a IT instruction). If BKPT instructions are used, then we might end up stopping on an instruction that won't get executed. So if we do stop at a BKPT instruction, we need to continue if the condition is not true. When using the BKPT isntructions are easy in that you don't need to detect the size of the breakpoint that needs to be used when setting a breakpoint even in a thumb IT instruction. The bad part is you will now always stop at the opcode location and let LLDB determine if it should auto-continue. If the BKPT instruction is used, the BKPT that is used for ARM code should be something that also triggers the BKPT instruction in Thumb in case you set a breakpoint in the middle of code and the code is actually Thumb code. A value of 0xE120BE70 will work since the lower 16 bits being 0xBE70 happens to be a Thumb BKPT instruction. The alternative is to use trap or illegal instructions that the kernel will translate into breakpoint hits. On Mac this was 0xE7FFDEFE for ARM and 0xDEFE for Thumb. The darwin kernel currently doesn't recognize any 32 bit Thumb instruction as a instruction that will get turned into a breakpoint exception (EXC_BREAKPOINT), so we had to use the BKPT instruction on Mac. The linux kernel recognizes a 16 and a 32 bit instruction as valid thumb breakpoint opcodes. The benefit of using 16 or 32 bit instructions is you don't stop on opcodes in a IT block when the condition doesn't match. To further complicate things, single stepping on ARM is often implemented by modifying the BCR/BVR registers and setting the processor to stop when the PC is not equal to the current value. This means single stepping is another way the ARM target can stop on instructions that won't get executed. This patch does the following: 1 - Fix the internal debugserver for Apple to use the BKPT instruction for ARM and Thumb 2 - Fix LLDB to catch when we stop in the middle of a Thumb IT instruction and continue if we stop at an instruction that won't execute 3 - Fixes this in a way that will work for any target on any platform as long as it is ARM/Thumb 4 - Adds a patch for ignoring conditions that don't match when in ARM mode (see below) This patch also provides the code that implements the same thing for ARM instructions, though it is disabled for now. The ARM patch will check the condition of the instruction in ARM mode and continue if the condition isn't true (and therefore the instruction would not be executed). Again, this is not enable, but the code for it has been added. <rdar://problem/19145455> llvm-svn: 223851
2014-12-10 07:31:02 +08:00
m_stop_info_override_callback = process_arch.GetStopInfoOverrideCallback();
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()
Figure out the reply to "PlanExplainsStop" once when we stop and then use the cached value. This fixes problems, for instance, with the StepRange plans, where they know that they explained the stop because they were at their "run to here" breakpoint, then deleted that breakpoint, so when they got asked again, doh! I had done this for a couple of plans in an ad hoc fashion, this just formalizes it. Also add a "ResumeRequested" in Process so that the code in the completion handlers can tell the ShouldStop logic they want to resume rather than just directly resuming. That allows us to handle resuming in a more controlled fashion. Also, SetPublicState can take a "restarted" flag, so that it doesn't drop the run lock when the target was immediately restarted. --This line, and those below , will be ignored-- M test/lang/objc/objc-dynamic-value/TestObjCDynamicValue.py M include/lldb/Target/ThreadList.h M include/lldb/Target/ThreadPlanStepOut.h M include/lldb/Target/Thread.h M include/lldb/Target/ThreadPlanBase.h M include/lldb/Target/ThreadPlanStepThrough.h M include/lldb/Target/ThreadPlanStepInstruction.h M include/lldb/Target/ThreadPlanStepInRange.h M include/lldb/Target/ThreadPlanStepOverBreakpoint.h M include/lldb/Target/ThreadPlanStepUntil.h M include/lldb/Target/StopInfo.h M include/lldb/Target/Process.h M include/lldb/Target/ThreadPlanRunToAddress.h M include/lldb/Target/ThreadPlan.h M include/lldb/Target/ThreadPlanCallFunction.h M include/lldb/Target/ThreadPlanStepOverRange.h M source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleThreadPlanStepThroughObjCTrampoline.h M source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleThreadPlanStepThroughObjCTrampoline.cpp M source/Target/StopInfo.cpp M source/Target/Process.cpp M source/Target/ThreadPlanRunToAddress.cpp M source/Target/ThreadPlan.cpp M source/Target/ThreadPlanCallFunction.cpp M source/Target/ThreadPlanStepOverRange.cpp M source/Target/ThreadList.cpp M source/Target/ThreadPlanStepOut.cpp M source/Target/Thread.cpp M source/Target/ThreadPlanBase.cpp M source/Target/ThreadPlanStepThrough.cpp M source/Target/ThreadPlanStepInstruction.cpp M source/Target/ThreadPlanStepInRange.cpp M source/Target/ThreadPlanStepOverBreakpoint.cpp M source/Target/ThreadPlanStepUntil.cpp M lldb.xcodeproj/xcshareddata/xcschemes/Run Testsuite.xcscheme llvm-svn: 181381
2013-05-08 08:35:16 +08:00
// to see if they are supposed to start back up with a signal.
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
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
{
Fix a race condition where you could set the selected thread & target in the CommandInterpreter's execution context AFTER the process had started running and before it initially stopped. Also fixed one test case that was implicitly using this (and an abuse of the async mode) to accidentally succeed. <rdar://problem/16814726> llvm-svn: 226528
2015-01-20 07:51:51 +08:00
// Somebody wanted to run without running (e.g. we were faking a step from one frame of a set of inlined
// frames that share the same PC to another.) So generate a continue & a stopped event,
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
// 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
Recommit "Fix race during process interruption" This is a resubmit of r254403, see that commit's message for context. This fixes an issue in the original commit, where we would incorrectly interrupt the process if the interrupt request came just as we were about to send the stopped event to the public. llvm-svn: 254902
2015-12-07 20:36:52 +08:00
Process::Halt (bool clear_thread_plans, bool use_run_lock)
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
{
Recommit "Fix race during process interruption" This is a resubmit of r254403, see that commit's message for context. This fixes an issue in the original commit, where we would incorrectly interrupt the process if the interrupt request came just as we were about to send the stopped event to the public. llvm-svn: 254902
2015-12-07 20:36:52 +08:00
if (! StateIsRunningState(m_public_state.GetValue()))
return Error("Process is not running.");
<rdar://problem/13700260> Avoid a deadlock when using the OperatingSystemPython code and typing "process interrupt". There was a possible lock inversion between the target API lock and the process' thread list lock due to code trying to discard the thread list. This was fixed by adding a boolean to Process::Halt() that indicates if the thread plans should be discarded and doing it in the private state thread when we process the stopped state. llvm-svn: 181651
2013-05-11 07:48:10 +08:00
// Don't clear the m_clear_thread_plans_on_stop, only set it to true if
// in case it was already set and some thread plan logic calls halt on its
// own.
m_clear_thread_plans_on_stop |= clear_thread_plans;
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");
Recommit "Fix race during process interruption" This is a resubmit of r254403, see that commit's message for context. This fixes an issue in the original commit, where we would incorrectly interrupt the process if the interrupt request came just as we were about to send the stopped event to the public. llvm-svn: 254902
2015-12-07 20:36:52 +08:00
HijackProcessEvents(&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;
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
Recommit "Fix race during process interruption" This is a resubmit of r254403, see that commit's message for context. This fixes an issue in the original commit, where we would incorrectly interrupt the process if the interrupt request came just as we were about to send the stopped event to the public. llvm-svn: 254902
2015-12-07 20:36:52 +08:00
SendAsyncInterrupt();
if (m_public_state.GetValue() == eStateAttaching)
Fix race during process interruption Summary: The following situation was occuring in TestAttachResume: - we did a "continue" from a breakpoint (which involves a private start-stop to step over the breakpoint) - after receiving the stop-reply from the step-over, we issue a "detach" (which requires a process interrupt) - at this moment, the public state is "running", private state is "about-to-be-stopped" (the stopped event was broadcast, but it was not received yet) - StopForDestroyOrDetach (public thread) notes the public state is running, sends an interrupt request to the private thread - private thread gets the eBroadcastBitInterrupt (before the eStateStopped message), and asks the process plugin to stop (via Halt()) - process plugin says it has nothing to do as the process is already stopped - private thread shrugs and carries on. receives the stop event, restores the breakpoint and resumes the process. - after a while, the public thread times out and says it failed to stop the process This patch does the following: - splits Halt() into two functions, private and public, their usage depends on the context - public Halt(): sends eBroadcastBitInterrupt to the private thread and waits for the Stop event - HaltPrivate(): asks the plugin to stop and makes a note that the halt was requested. When the next stop event comes it sets the interrupt flag on it. - removes HijackPrivateProcessEvents(), as the only user (old Halt()) has gone away - removes the m_currently_handling_event hack, as the new Halt() does not need it - adds a use_run_lock parameter to public Halt() and WaitForProcessToStop(). This was needed because RunThreadPlan uses Halt() while holding the run lock and we don't want Halt() to take it away from him. Reviewers: clayborg, jingham Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D14989 llvm-svn: 254403
2015-12-01 19:28:47 +08:00
{
Recommit "Fix race during process interruption" This is a resubmit of r254403, see that commit's message for context. This fixes an issue in the original commit, where we would incorrectly interrupt the process if the interrupt request came just as we were about to send the stopped event to the public. llvm-svn: 254902
2015-12-07 20:36:52 +08:00
// Don't hijack and eat the eStateExited as the code that was doing
// the attach will be waiting for this event...
RestoreProcessEvents();
SetExitStatus(SIGKILL, "Cancelled async attach.");
Destroy (false);
return Error();
Fix race during process interruption Summary: The following situation was occuring in TestAttachResume: - we did a "continue" from a breakpoint (which involves a private start-stop to step over the breakpoint) - after receiving the stop-reply from the step-over, we issue a "detach" (which requires a process interrupt) - at this moment, the public state is "running", private state is "about-to-be-stopped" (the stopped event was broadcast, but it was not received yet) - StopForDestroyOrDetach (public thread) notes the public state is running, sends an interrupt request to the private thread - private thread gets the eBroadcastBitInterrupt (before the eStateStopped message), and asks the process plugin to stop (via Halt()) - process plugin says it has nothing to do as the process is already stopped - private thread shrugs and carries on. receives the stop event, restores the breakpoint and resumes the process. - after a while, the public thread times out and says it failed to stop the process This patch does the following: - splits Halt() into two functions, private and public, their usage depends on the context - public Halt(): sends eBroadcastBitInterrupt to the private thread and waits for the Stop event - HaltPrivate(): asks the plugin to stop and makes a note that the halt was requested. When the next stop event comes it sets the interrupt flag on it. - removes HijackPrivateProcessEvents(), as the only user (old Halt()) has gone away - removes the m_currently_handling_event hack, as the new Halt() does not need it - adds a use_run_lock parameter to public Halt() and WaitForProcessToStop(). This was needed because RunThreadPlan uses Halt() while holding the run lock and we don't want Halt() to take it away from him. Reviewers: clayborg, jingham Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D14989 llvm-svn: 254403
2015-12-01 19:28:47 +08:00
}
Recommit "Fix race during process interruption" This is a resubmit of r254403, see that commit's message for context. This fixes an issue in the original commit, where we would incorrectly interrupt the process if the interrupt request came just as we were about to send the stopped event to the public. llvm-svn: 254902
2015-12-07 20:36:52 +08:00
// Wait for 10 second for the process to stop.
TimeValue timeout_time;
timeout_time = TimeValue::Now();
timeout_time.OffsetWithSeconds(10);
StateType state = WaitForProcessToStop(&timeout_time, &event_sp, true, &halt_listener,
nullptr, use_run_lock);
RestoreProcessEvents();
Fix race during process interruption Summary: The following situation was occuring in TestAttachResume: - we did a "continue" from a breakpoint (which involves a private start-stop to step over the breakpoint) - after receiving the stop-reply from the step-over, we issue a "detach" (which requires a process interrupt) - at this moment, the public state is "running", private state is "about-to-be-stopped" (the stopped event was broadcast, but it was not received yet) - StopForDestroyOrDetach (public thread) notes the public state is running, sends an interrupt request to the private thread - private thread gets the eBroadcastBitInterrupt (before the eStateStopped message), and asks the process plugin to stop (via Halt()) - process plugin says it has nothing to do as the process is already stopped - private thread shrugs and carries on. receives the stop event, restores the breakpoint and resumes the process. - after a while, the public thread times out and says it failed to stop the process This patch does the following: - splits Halt() into two functions, private and public, their usage depends on the context - public Halt(): sends eBroadcastBitInterrupt to the private thread and waits for the Stop event - HaltPrivate(): asks the plugin to stop and makes a note that the halt was requested. When the next stop event comes it sets the interrupt flag on it. - removes HijackPrivateProcessEvents(), as the only user (old Halt()) has gone away - removes the m_currently_handling_event hack, as the new Halt() does not need it - adds a use_run_lock parameter to public Halt() and WaitForProcessToStop(). This was needed because RunThreadPlan uses Halt() while holding the run lock and we don't want Halt() to take it away from him. Reviewers: clayborg, jingham Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D14989 llvm-svn: 254403
2015-12-01 19:28:47 +08:00
Recommit "Fix race during process interruption" This is a resubmit of r254403, see that commit's message for context. This fixes an issue in the original commit, where we would incorrectly interrupt the process if the interrupt request came just as we were about to send the stopped event to the public. llvm-svn: 254902
2015-12-07 20:36:52 +08:00
if (state == eStateInvalid || ! event_sp)
{
// We timed out and didn't get a stop event...
return Error("Halt timed out. State = %s", StateAsCString(GetState()));
}
BroadcastEvent(event_sp);
return Error();
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +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
Resumbit "Fix race condition during process detach" This is a resubmission of r248371. It also incorporates the process event hijack patch by Kyrill Lapshin in D12968. llvm-svn: 249554
2015-10-07 23:11:11 +08:00
Process::StopForDestroyOrDetach(lldb::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
{
Error error;
if (m_public_state.GetValue() == eStateRunning)
{
Log *log(lldb_private::GetLogIfAllCategoriesSet (LIBLLDB_LOG_PROCESS));
if (log)
Resumbit "Fix race condition during process detach" This is a resubmission of r248371. It also incorporates the process event hijack patch by Kyrill Lapshin in D12968. llvm-svn: 249554
2015-10-07 23:11:11 +08:00
log->Printf("Process::%s() About to stop.", __FUNCTION__);
ListenerSP listener_sp (new Listener("lldb.Process.StopForDestroyOrDetach.hijack"));
HijackProcessEvents(listener_sp.get());
SendAsyncInterrupt();
// Consume the interrupt event.
TimeValue timeout (TimeValue::Now());
timeout.OffsetWithSeconds(10);
StateType state = WaitForProcessToStop (&timeout, &exit_event_sp, true, listener_sp.get());
RestoreProcessEvents();
// 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)
Rationalize how we do Halt-ing before Destroy and Detach. <rdar://problem/13527167> llvm-svn: 178325
2013-03-29 09:18:12 +08:00
{
Resumbit "Fix race condition during process detach" This is a resubmission of r248371. It also incorporates the process event hijack patch by Kyrill Lapshin in D12968. llvm-svn: 249554
2015-10-07 23:11:11 +08:00
if (log)
log->Printf("Process::%s() Process exited while waiting to stop.", __FUNCTION__);
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
}
else
Resumbit "Fix race condition during process detach" This is a resubmission of r248371. It also incorporates the process event hijack patch by Kyrill Lapshin in D12968. llvm-svn: 249554
2015-10-07 23:11:11 +08:00
exit_event_sp.reset(); // It is ok to consume any non-exit stop events
if (state != eStateStopped)
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 (log)
Resumbit "Fix race condition during process detach" This is a resubmission of r248371. It also incorporates the process event hijack patch by Kyrill Lapshin in D12968. llvm-svn: 249554
2015-10-07 23:11:11 +08:00
log->Printf("Process::%s() failed to stop, state is: %s", __FUNCTION__, 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;
}
Rationalize how we do Halt-ing before Destroy and Detach. <rdar://problem/13527167> llvm-svn: 178325
2013-03-29 09:18:12 +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
Recommitting r180831 with trivial fix - remember to return errors if you compute. llvm-svn: 180898
2013-05-02 08:27:30 +08:00
Process::Detach (bool keep_stopped)
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +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
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())
{
Resumbit "Fix race condition during process detach" This is a resubmission of r248371. It also incorporates the process event hijack patch by Kyrill Lapshin in D12968. llvm-svn: 249554
2015-10-07 23:11:11 +08:00
error = StopForDestroyOrDetach (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 (!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;
}
}
Move calls to DisableAllBreakpointSites() and m_thread_list.DiscardThreadPlans() into base Process::Destroy() instead of in subclass DoDestroy() methods. llvm-svn: 204752
2014-03-26 03:59:36 +08:00
m_thread_list.DiscardThreadPlans();
DisableAllBreakpointSites();
Recommitting r180831 with trivial fix - remember to return errors if you compute. llvm-svn: 180898
2013-05-02 08:27:30 +08:00
error = DoDetach(keep_stopped);
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
if (error.Success())
{
DidDetach();
StopPrivateStateThread();
}
Recommitting r180831 with trivial fix - remember to return errors if you compute. llvm-svn: 180898
2013-05-02 08:27:30 +08:00
else
{
return error;
}
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +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
m_destroy_in_process = false;
// If we exited when we were waiting for a process to stop, then
// forward the event here so we don't lose the event
if (exit_event_sp)
{
// Directly broadcast our exited event because we shut down our
// private state thread above
BroadcastEvent(exit_event_sp);
}
// If we have been interrupted (to kill us) in the middle of running, we may not end up propagating
// the last events through the event system, in which case we might strand the write lock. Unlock
// it here so when we do to tear down the process we don't get an error destroying the lock.
Use flag instead of rwlock state to track process running state LLDB requires that the inferior process be stopped before, and remain stopped during, certain accesses to process state. Previously this was achieved with a POSIX rwlock which had a write lock taken for the duration that the process was running, and released when the process was stopped. Any access to process state was performed with a read lock held. However, POSIX requires that pthread_rwlock_unlock() be called from the same thread as pthread_rwlock_wrlock(), and lldb needs to stop and start the process from different threads. Violating this constraint is technically undefined behaviour, although as it happens Linux and Darwin result in the unlock proceeding in this case. FreeBSD follows POSIX more strictly, and the unlock would fail, resulting in a hang later upon the next attempt to take the lock. All read lock consumers use ReadTryLock() and handle failure to obtain the lock (typically by logging an error "process is running"). Thus, instead of using the lock state itself to track the running state, this change adds an explicit m_running flag. ReadTryLock tests the flag, and if the process is not running it returns with the read lock held. WriteLock and WriteTryLock are renamed to SetRunning and TrySetRunning, and (if successful) they set m_running with the lock held. This way, read consumers can determine if the process is running and act appropriately, and write consumers are still held off from starting the process if read consumers are active. Note that with this change there are still some curious access patterns, such as calling WriteUnlock / SetStopped twice in a row, and there's no protection from multiple threads trying to simultaneously start the process. In practice this does not seem to be a problem, and was exposing other undefined POSIX behaviour prior to this change. llvm-svn: 187377
2013-07-30 04:58:06 +08:00
m_public_run_lock.SetStopped();
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
return error;
}
Error
Add a "force_kill" arg to Process::Destroy(). This is needed after the changes in r233255/r233258. Normally if lldb attaches to a running process, when we call Process::Destroy, we want to detach from the process. If lldb launched the process itself, ::Destroy should kill it. However, if we attach to a process and the driver calls SBProcess::Kill() (which calls Destroy), we need to kill it even if we didn't launch it originally. The force_kill param allows for the SBProcess::Kill method to force the behavior of Destroy. <rdar://problem/20424439> llvm-svn: 235158
2015-04-17 13:01:58 +08:00
Process::Destroy (bool force_kill)
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
{
Recommit "Fix race during process interruption" This is a resubmit of r254403, see that commit's message for context. This fixes an issue in the original commit, where we would incorrectly interrupt the process if the interrupt request came just as we were about to send the stopped event to the public. llvm-svn: 254902
2015-12-07 20:36:52 +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
// 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.
Add a "force_kill" arg to Process::Destroy(). This is needed after the changes in r233255/r233258. Normally if lldb attaches to a running process, when we call Process::Destroy, we want to detach from the process. If lldb launched the process itself, ::Destroy should kill it. However, if we attach to a process and the driver calls SBProcess::Kill() (which calls Destroy), we need to kill it even if we didn't launch it originally. The force_kill param allows for the SBProcess::Kill method to force the behavior of Destroy. <rdar://problem/20424439> llvm-svn: 235158
2015-04-17 13:01:58 +08:00
if (force_kill)
m_should_detach = false;
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
Fix -gdb-exit to detach if was attached or destroy otherwise (MI) Summary: This patch fixes -gdb-exit for locally target. It includes the following changes: # Fix Process::Finalize # Use SBProcess::Destroy in -gdb-exit Reviewers: abidh, zturner, clayborg Reviewed By: clayborg Subscribers: lldb-commits, clayborg, abidh Differential Revision: http://reviews.llvm.org/D8298 llvm-svn: 233255
2015-03-26 15:08:47 +08:00
if (GetShouldDetach())
{
// FIXME: This will have to be a process setting:
bool keep_stopped = false;
Detach(keep_stopped);
}
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 = 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
{
Resumbit "Fix race condition during process detach" This is a resubmission of r248371. It also incorporates the process event hijack patch by Kyrill Lapshin in D12968. llvm-svn: 249554
2015-10-07 23:11:11 +08:00
error = StopForDestroyOrDetach(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.Disconnect();
Fixed a deadlock that was slowing down processes when they shut down. A 3 second delay could occur sometimes when a process exits, now that delay is gone. llvm-svn: 238893
2015-06-03 08:34:01 +08:00
m_stdio_communication.StopReadThread();
Fix 'process launch -i' for remote processes We want to forward stdin when stdio is not disabled and when we're not redirecting stdin from a file. renamed m_stdio_disable to m_stdin_forward and inverted value because that's what we want to remember. There was previously a bug that if you redirected stdin from a file, stdout and stderr would also be redirected to /dev/null Adds support for remote target to TestProcessIO.py Fixes ProcessIOTestCase.test_stdin_redirection_with_dwarf for remote Linux targets llvm-svn: 228744
2015-02-11 05:09:04 +08:00
m_stdin_forward = false;
Fixed all overlapping prompt issues. I carefully reviewed exactly how the IOHandlers interact and found places where we weren't properly controlling things. There should be no overlapping prompts and all output should now come out in a controlled fashion. <rdar://problem/16111293> llvm-svn: 202525
2014-03-01 02:22:24 +08:00
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
if (m_process_input_reader)
Fixed all overlapping prompt issues. I carefully reviewed exactly how the IOHandlers interact and found places where we weren't properly controlling things. There should be no overlapping prompts and all output should now come out in a controlled fashion. <rdar://problem/16111293> llvm-svn: 202525
2014-03-01 02:22:24 +08:00
{
m_process_input_reader->SetIsDone(true);
m_process_input_reader->Cancel();
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();
Fixed all overlapping prompt issues. I carefully reviewed exactly how the IOHandlers interact and found places where we weren't properly controlling things. There should be no overlapping prompts and all output should now come out in a controlled fashion. <rdar://problem/16111293> llvm-svn: 202525
2014-03-01 02:22:24 +08:00
}
<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.
Use flag instead of rwlock state to track process running state LLDB requires that the inferior process be stopped before, and remain stopped during, certain accesses to process state. Previously this was achieved with a POSIX rwlock which had a write lock taken for the duration that the process was running, and released when the process was stopped. Any access to process state was performed with a read lock held. However, POSIX requires that pthread_rwlock_unlock() be called from the same thread as pthread_rwlock_wrlock(), and lldb needs to stop and start the process from different threads. Violating this constraint is technically undefined behaviour, although as it happens Linux and Darwin result in the unlock proceeding in this case. FreeBSD follows POSIX more strictly, and the unlock would fail, resulting in a hang later upon the next attempt to take the lock. All read lock consumers use ReadTryLock() and handle failure to obtain the lock (typically by logging an error "process is running"). Thus, instead of using the lock state itself to track the running state, this change adds an explicit m_running flag. ReadTryLock tests the flag, and if the process is not running it returns with the read lock held. WriteLock and WriteTryLock are renamed to SetRunning and TrySetRunning, and (if successful) they set m_running with the lock held. This way, read consumers can determine if the process is running and act appropriately, and write consumers are still held off from starting the process if read consumers are active. Note that with this change there are still some curious access patterns, such as calling WriteUnlock / SetStopped twice in a row, and there's no protection from multiple threads trying to simultaneously start the process. In practice this does not seem to be a problem, and was exposing other undefined POSIX behaviour prior to this change. llvm-svn: 187377
2013-07-30 04:58:06 +08:00
m_public_run_lock.SetStopped();
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;
}
Further reduce the header footprint of Process.h No functional change here, only deletes unnecessary headers and moves one function's body from the .h file to the .cpp. llvm-svn: 231145
2015-03-04 05:51:25 +08:00
void
Make ProcessGDBRemote get a //copy// of platform Unix signals. Summary: Update to http://reviews.llvm.org/rL243618. Reviewers: jaydeep, clayborg Subscribers: labath, tberghammer, lldb-commits Differential Revision: http://reviews.llvm.org/D12420 llvm-svn: 246557
2015-09-02 00:58:45 +08:00
Process::SetUnixSignals(UnixSignalsSP &&signals_sp)
Further reduce the header footprint of Process.h No functional change here, only deletes unnecessary headers and moves one function's body from the .h file to the .cpp. llvm-svn: 231145
2015-03-04 05:51:25 +08:00
{
assert (signals_sp && "null signals_sp");
m_unix_signals_sp = signals_sp;
}
Refactor Unix signals. Summary: - Consolidate Unix signals selection in UnixSignals. - Make Unix signals available from platform. - Add jSignalsInfo packet to retrieve Unix signals from remote platform. - Get a copy of the platform signal for each remote process. - Update SB API for signals. - Update signal utility in test suite. Reviewers: ovyalov, clayborg Subscribers: chaoren, jingham, labath, emaste, tberghammer, lldb-commits Differential Revision: http://reviews.llvm.org/D11094 llvm-svn: 242101
2015-07-14 09:09:28 +08:00
const lldb::UnixSignalsSP &
Further reduce the header footprint of Process.h No functional change here, only deletes unnecessary headers and moves one function's body from the .h file to the .cpp. llvm-svn: 231145
2015-03-04 05:51:25 +08:00
Process::GetUnixSignals ()
{
assert (m_unix_signals_sp && "null m_unix_signals_sp");
Refactor Unix signals. Summary: - Consolidate Unix signals selection in UnixSignals. - Make Unix signals available from platform. - Add jSignalsInfo packet to retrieve Unix signals from remote platform. - Get a copy of the platform signal for each remote process. - Update SB API for signals. - Update signal utility in test suite. Reviewers: ovyalov, clayborg Subscribers: chaoren, jingham, labath, emaste, tberghammer, lldb-commits Differential Revision: http://reviews.llvm.org/D11094 llvm-svn: 242101
2015-07-14 09:09:28 +08:00
return m_unix_signals_sp;
Further reduce the header footprint of Process.h No functional change here, only deletes unnecessary headers and moves one function's body from the .h file to the .cpp. llvm-svn: 231145
2015-03-04 05:51:25 +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
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
{
Have the Process hold a weak_ptr to the Target. llvm-svn: 246578
2015-09-02 04:02:29 +08:00
return GetTarget().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
{
Have the Process hold a weak_ptr to the Target. llvm-svn: 246578
2015-09-02 04:02:29 +08:00
return GetTarget().GetArchitecture().GetAddressByteSize();
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)
{
case eStateDetached:
case eStateExited:
case eStateUnloaded:
Fix ProcessIO test failures Summary: There was a race condition regarding the output of the inferior process. The reading of the output is performed on a separate thread, and there was no guarantee that the output will get eventually consumed. Because of that, it was happening that calling Process::GetSTDOUT was not returning anything even though the process was terminated and would definitely not produce any further output. This was usually happening only under very heavy system load, but it can be reproduced by placing an usleep in the stdio thread (Process::STDIOReadThreadBytesReceived). This patch addresses this by adding synchronization capabilities to the Communication thread. After calling Communication::SynchronizeWithReadThread one can be sure that all pending input has been processed by the read thread. This function is then called after every public event which stops the process to obtain the entire process output. Test Plan: TestProcessIO.py should now succeed every time instead of flaking in and out. Reviewers: clayborg, jingham Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D8246 llvm-svn: 232023
2015-03-12 18:12:41 +08:00
m_stdio_communication.SynchronizeWithReadThread();
Fix rare failure in TestProcessIO Summary: There was a race condition in Process class, where we would not wait for process stdout to propagate fully before we would shut down the connection (repro case: slow down the stdio thread by placing a sleep right at the end of the while loop in Communication::ReadThread). The Process class already tried to solve this problem by synchronizing with the read thread in Process::ShouldBroadcastEvent, but unfortunately the connection got closed before that in Process::SetExitStatus. I solve this issue by delaying the connection shutdown until we get a chance to process the event and synchronize. Alternatively, I could have moved the synchronization point to an earlier point in SetExitStatus, but it seems safer to delay the shutdown until other things get a chance to notice the process has exited. Reviewers: clayborg, ovyalov Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D12558 llvm-svn: 246753
2015-09-03 17:30:17 +08:00
m_stdio_communication.Disconnect();
m_stdio_communication.StopReadThread();
m_stdin_forward = false;
Fix ProcessIO test failures Summary: There was a race condition regarding the output of the inferior process. The reading of the output is performed on a separate thread, and there was no guarantee that the output will get eventually consumed. Because of that, it was happening that calling Process::GetSTDOUT was not returning anything even though the process was terminated and would definitely not produce any further output. This was usually happening only under very heavy system load, but it can be reproduced by placing an usleep in the stdio thread (Process::STDIOReadThreadBytesReceived). This patch addresses this by adding synchronization capabilities to the Communication thread. After calling Communication::SynchronizeWithReadThread one can be sure that all pending input has been processed by the read thread. This function is then called after every public event which stops the process to obtain the entire process output. Test Plan: TestProcessIO.py should now succeed every time instead of flaking in and out. Reviewers: clayborg, jingham Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D8246 llvm-svn: 232023
2015-03-12 18:12:41 +08:00
// fall-through
case eStateConnected:
case eStateAttaching:
case eStateLaunching:
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
// 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);
Get the breakpoint setting, and the Mac OS X DYLD trampolines and expression evaluator to handle Indirect symbols correctly. There were a couple of pieces to this. 1) When a breakpoint location finds itself pointing to an Indirect symbol, when the site for it is created it needs to resolve the symbol and actually set the site at its target. 2) Not all breakpoints want to do this (i.e. a straight address breakpoint should always set itself on the specified address, so somem machinery was needed to specify that. 3) I added some info to the break list output for indirect symbols so you could see what was happening. Also I made it clear when we re-route through re-exported symbols. 4) I moved ResolveIndirectFunction from ProcessPosix to Process since it works the exact same way on Mac OS X and the other posix systems. If we find a platform that doesn't do it this way, they can override the call in Process. 5) Fixed one bug in RunThreadPlan, if you were trying to run a thread plan after a "running" event had been broadcast, the event coalescing would cause you to miss the ThreadPlan running event. So I added a way to override the coalescing. 6) Made DynamicLoaderMacOSXDYLD::GetStepThroughTrampolinePlan handle Indirect & Re-exported symbols. <rdar://problem/15280639> llvm-svn: 198976
2014-01-11 07:46:59 +08:00
if (m_force_next_event_delivery)
return_value = true;
else
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
{
Get the breakpoint setting, and the Mac OS X DYLD trampolines and expression evaluator to handle Indirect symbols correctly. There were a couple of pieces to this. 1) When a breakpoint location finds itself pointing to an Indirect symbol, when the site for it is created it needs to resolve the symbol and actually set the site at its target. 2) Not all breakpoints want to do this (i.e. a straight address breakpoint should always set itself on the specified address, so somem machinery was needed to specify that. 3) I added some info to the break list output for indirect symbols so you could see what was happening. Also I made it clear when we re-route through re-exported symbols. 4) I moved ResolveIndirectFunction from ProcessPosix to Process since it works the exact same way on Mac OS X and the other posix systems. If we find a platform that doesn't do it this way, they can override the call in Process. 5) Fixed one bug in RunThreadPlan, if you were trying to run a thread plan after a "running" event had been broadcast, the event coalescing would cause you to miss the ThreadPlan running event. So I added a way to override the coalescing. 6) Made DynamicLoaderMacOSXDYLD::GetStepThroughTrampolinePlan handle Indirect & Re-exported symbols. <rdar://problem/15280639> llvm-svn: 198976
2014-01-11 07:46:59 +08:00
switch (m_last_broadcast_state)
{
case eStateRunning:
case eStateStepping:
// We always suppress multiple runnings with no PUBLIC stop in between.
return_value = false;
break;
default:
// TODO: make this work correctly. For now always report
Fix typos. llvm-svn: 212132
2014-07-02 05:22:11 +08:00
// run if we aren't running so we don't miss any running
Get the breakpoint setting, and the Mac OS X DYLD trampolines and expression evaluator to handle Indirect symbols correctly. There were a couple of pieces to this. 1) When a breakpoint location finds itself pointing to an Indirect symbol, when the site for it is created it needs to resolve the symbol and actually set the site at its target. 2) Not all breakpoints want to do this (i.e. a straight address breakpoint should always set itself on the specified address, so somem machinery was needed to specify that. 3) I added some info to the break list output for indirect symbols so you could see what was happening. Also I made it clear when we re-route through re-exported symbols. 4) I moved ResolveIndirectFunction from ProcessPosix to Process since it works the exact same way on Mac OS X and the other posix systems. If we find a platform that doesn't do it this way, they can override the call in Process. 5) Fixed one bug in RunThreadPlan, if you were trying to run a thread plan after a "running" event had been broadcast, the event coalescing would cause you to miss the ThreadPlan running event. So I added a way to override the coalescing. 6) Made DynamicLoaderMacOSXDYLD::GetStepThroughTrampolinePlan handle Indirect & Re-exported symbols. <rdar://problem/15280639> llvm-svn: 198976
2014-01-11 07:46:59 +08:00
// 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;
}
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
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.
Figure out the reply to "PlanExplainsStop" once when we stop and then use the cached value. This fixes problems, for instance, with the StepRange plans, where they know that they explained the stop because they were at their "run to here" breakpoint, then deleted that breakpoint, so when they got asked again, doh! I had done this for a couple of plans in an ad hoc fashion, this just formalizes it. Also add a "ResumeRequested" in Process so that the code in the completion handlers can tell the ShouldStop logic they want to resume rather than just directly resuming. That allows us to handle resuming in a more controlled fashion. Also, SetPublicState can take a "restarted" flag, so that it doesn't drop the run lock when the target was immediately restarted. --This line, and those below , will be ignored-- M test/lang/objc/objc-dynamic-value/TestObjCDynamicValue.py M include/lldb/Target/ThreadList.h M include/lldb/Target/ThreadPlanStepOut.h M include/lldb/Target/Thread.h M include/lldb/Target/ThreadPlanBase.h M include/lldb/Target/ThreadPlanStepThrough.h M include/lldb/Target/ThreadPlanStepInstruction.h M include/lldb/Target/ThreadPlanStepInRange.h M include/lldb/Target/ThreadPlanStepOverBreakpoint.h M include/lldb/Target/ThreadPlanStepUntil.h M include/lldb/Target/StopInfo.h M include/lldb/Target/Process.h M include/lldb/Target/ThreadPlanRunToAddress.h M include/lldb/Target/ThreadPlan.h M include/lldb/Target/ThreadPlanCallFunction.h M include/lldb/Target/ThreadPlanStepOverRange.h M source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleThreadPlanStepThroughObjCTrampoline.h M source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleThreadPlanStepThroughObjCTrampoline.cpp M source/Target/StopInfo.cpp M source/Target/Process.cpp M source/Target/ThreadPlanRunToAddress.cpp M source/Target/ThreadPlan.cpp M source/Target/ThreadPlanCallFunction.cpp M source/Target/ThreadPlanStepOverRange.cpp M source/Target/ThreadList.cpp M source/Target/ThreadPlanStepOut.cpp M source/Target/Thread.cpp M source/Target/ThreadPlanBase.cpp M source/Target/ThreadPlanStepThrough.cpp M source/Target/ThreadPlanStepInstruction.cpp M source/Target/ThreadPlanStepInRange.cpp M source/Target/ThreadPlanStepOverBreakpoint.cpp M source/Target/ThreadPlanStepUntil.cpp M lldb.xcodeproj/xcshareddata/xcschemes/Run Testsuite.xcscheme llvm-svn: 181381
2013-05-08 08:35:16 +08:00
Fix ProcessIO test failures Summary: There was a race condition regarding the output of the inferior process. The reading of the output is performed on a separate thread, and there was no guarantee that the output will get eventually consumed. Because of that, it was happening that calling Process::GetSTDOUT was not returning anything even though the process was terminated and would definitely not produce any further output. This was usually happening only under very heavy system load, but it can be reproduced by placing an usleep in the stdio thread (Process::STDIOReadThreadBytesReceived). This patch addresses this by adding synchronization capabilities to the Communication thread. After calling Communication::SynchronizeWithReadThread one can be sure that all pending input has been processed by the read thread. This function is then called after every public event which stops the process to obtain the entire process output. Test Plan: TestProcessIO.py should now succeed every time instead of flaking in and out. Reviewers: clayborg, jingham Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D8246 llvm-svn: 232023
2015-03-12 18:12:41 +08:00
m_stdio_communication.SynchronizeWithReadThread();
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",
sweep up -Wformat warnings from gcc This is a purely mechanical change explicitly casting any parameters for printf style conversion. This cleans up the warnings emitted by gcc 4.8 on Linux. llvm-svn: 205607
2014-04-04 12:06:10 +08:00
static_cast<void*>(event_ptr),
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
StateAsCString(state));
Fix the behavior when hand-calling a function times out on one thread, but by the time we go to halt, it has already stopped by hitting the function end breakpoint. That wasn't being shown to the threads so the Function call thread plan didn't know its job was done. <rdar://problem/16515785> llvm-svn: 205803
2014-04-09 05:33:21 +08:00
// Even though we know we are going to stop, we should let the threads have a look at the stop,
// so they can properly set their state.
m_thread_list.ShouldStop (event_ptr);
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;
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
{
Figure out the reply to "PlanExplainsStop" once when we stop and then use the cached value. This fixes problems, for instance, with the StepRange plans, where they know that they explained the stop because they were at their "run to here" breakpoint, then deleted that breakpoint, so when they got asked again, doh! I had done this for a couple of plans in an ad hoc fashion, this just formalizes it. Also add a "ResumeRequested" in Process so that the code in the completion handlers can tell the ShouldStop logic they want to resume rather than just directly resuming. That allows us to handle resuming in a more controlled fashion. Also, SetPublicState can take a "restarted" flag, so that it doesn't drop the run lock when the target was immediately restarted. --This line, and those below , will be ignored-- M test/lang/objc/objc-dynamic-value/TestObjCDynamicValue.py M include/lldb/Target/ThreadList.h M include/lldb/Target/ThreadPlanStepOut.h M include/lldb/Target/Thread.h M include/lldb/Target/ThreadPlanBase.h M include/lldb/Target/ThreadPlanStepThrough.h M include/lldb/Target/ThreadPlanStepInstruction.h M include/lldb/Target/ThreadPlanStepInRange.h M include/lldb/Target/ThreadPlanStepOverBreakpoint.h M include/lldb/Target/ThreadPlanStepUntil.h M include/lldb/Target/StopInfo.h M include/lldb/Target/Process.h M include/lldb/Target/ThreadPlanRunToAddress.h M include/lldb/Target/ThreadPlan.h M include/lldb/Target/ThreadPlanCallFunction.h M include/lldb/Target/ThreadPlanStepOverRange.h M source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleThreadPlanStepThroughObjCTrampoline.h M source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleThreadPlanStepThroughObjCTrampoline.cpp M source/Target/StopInfo.cpp M source/Target/Process.cpp M source/Target/ThreadPlanRunToAddress.cpp M source/Target/ThreadPlan.cpp M source/Target/ThreadPlanCallFunction.cpp M source/Target/ThreadPlanStepOverRange.cpp M source/Target/ThreadList.cpp M source/Target/ThreadPlanStepOut.cpp M source/Target/Thread.cpp M source/Target/ThreadPlanBase.cpp M source/Target/ThreadPlanStepThrough.cpp M source/Target/ThreadPlanStepInstruction.cpp M source/Target/ThreadPlanStepInRange.cpp M source/Target/ThreadPlanStepOverBreakpoint.cpp M source/Target/ThreadPlanStepUntil.cpp M lldb.xcodeproj/xcshareddata/xcschemes/Run Testsuite.xcscheme llvm-svn: 181381
2013-05-08 08:35:16 +08:00
bool was_restarted = ProcessEventData::GetRestartedFromEvent (event_ptr);
bool should_resume = false;
sweep up -Wformat warnings from gcc This is a purely mechanical change explicitly casting any parameters for printf style conversion. This cleans up the warnings emitted by gcc 4.8 on Linux. llvm-svn: 205607
2014-04-04 12:06:10 +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.
sweep up -Wformat warnings from gcc This is a purely mechanical change explicitly casting any parameters for printf style conversion. This cleans up the warnings emitted by gcc 4.8 on Linux. llvm-svn: 205607
2014-04-04 12:06:10 +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 (!was_restarted)
should_resume = m_thread_list.ShouldStop (event_ptr) == false;
sweep up -Wformat warnings from gcc This is a purely mechanical change explicitly casting any parameters for printf style conversion. This cleans up the warnings emitted by gcc 4.8 on Linux. llvm-svn: 205607
2014-04-04 12:06:10 +08:00
Figure out the reply to "PlanExplainsStop" once when we stop and then use the cached value. This fixes problems, for instance, with the StepRange plans, where they know that they explained the stop because they were at their "run to here" breakpoint, then deleted that breakpoint, so when they got asked again, doh! I had done this for a couple of plans in an ad hoc fashion, this just formalizes it. Also add a "ResumeRequested" in Process so that the code in the completion handlers can tell the ShouldStop logic they want to resume rather than just directly resuming. That allows us to handle resuming in a more controlled fashion. Also, SetPublicState can take a "restarted" flag, so that it doesn't drop the run lock when the target was immediately restarted. --This line, and those below , will be ignored-- M test/lang/objc/objc-dynamic-value/TestObjCDynamicValue.py M include/lldb/Target/ThreadList.h M include/lldb/Target/ThreadPlanStepOut.h M include/lldb/Target/Thread.h M include/lldb/Target/ThreadPlanBase.h M include/lldb/Target/ThreadPlanStepThrough.h M include/lldb/Target/ThreadPlanStepInstruction.h M include/lldb/Target/ThreadPlanStepInRange.h M include/lldb/Target/ThreadPlanStepOverBreakpoint.h M include/lldb/Target/ThreadPlanStepUntil.h M include/lldb/Target/StopInfo.h M include/lldb/Target/Process.h M include/lldb/Target/ThreadPlanRunToAddress.h M include/lldb/Target/ThreadPlan.h M include/lldb/Target/ThreadPlanCallFunction.h M include/lldb/Target/ThreadPlanStepOverRange.h M source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleThreadPlanStepThroughObjCTrampoline.h M source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleThreadPlanStepThroughObjCTrampoline.cpp M source/Target/StopInfo.cpp M source/Target/Process.cpp M source/Target/ThreadPlanRunToAddress.cpp M source/Target/ThreadPlan.cpp M source/Target/ThreadPlanCallFunction.cpp M source/Target/ThreadPlanStepOverRange.cpp M source/Target/ThreadList.cpp M source/Target/ThreadPlanStepOut.cpp M source/Target/Thread.cpp M source/Target/ThreadPlanBase.cpp M source/Target/ThreadPlanStepThrough.cpp M source/Target/ThreadPlanStepInstruction.cpp M source/Target/ThreadPlanStepInRange.cpp M source/Target/ThreadPlanStepOverBreakpoint.cpp M source/Target/ThreadPlanStepUntil.cpp M lldb.xcodeproj/xcshareddata/xcschemes/Run Testsuite.xcscheme llvm-svn: 181381
2013-05-08 08:35:16 +08:00
if (was_restarted || should_resume || m_resume_requested)
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)
Fix a typo in Process.cpp llvm-svn: 256852
2016-01-06 01:55:32 +08:00
log->Printf ("Process::ShouldBroadcastEvent: should_resume: %i state: %s was_restarted: %i stop_vote: %d.",
sweep up -Wformat warnings from gcc This is a purely mechanical change explicitly casting any parameters for printf style conversion. This cleans up the warnings emitted by gcc 4.8 on Linux. llvm-svn: 205607
2014-04-04 12:06:10 +08:00
should_resume, StateAsCString(state),
was_restarted, stop_vote);
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 (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;
}
sweep up -Wformat warnings from gcc This is a purely mechanical change explicitly casting any parameters for printf style conversion. This cleans up the warnings emitted by gcc 4.8 on Linux. llvm-svn: 205607
2014-04-04 12:06:10 +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)
sweep up -Wformat warnings from gcc This is a purely mechanical change explicitly casting any parameters for printf style conversion. This cleans up the warnings emitted by gcc 4.8 on Linux. llvm-svn: 205607
2014-04-04 12:06:10 +08:00
log->Printf ("Process::ShouldBroadcastEvent (%p) Restarting process from state: %s",
static_cast<void*>(event_ptr),
StateAsCString(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
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
}
sweep up -Wformat warnings from gcc This is a purely mechanical change explicitly casting any parameters for printf style conversion. This cleans up the warnings emitted by gcc 4.8 on Linux. llvm-svn: 205607
2014-04-04 12:06:10 +08:00
Get the breakpoint setting, and the Mac OS X DYLD trampolines and expression evaluator to handle Indirect symbols correctly. There were a couple of pieces to this. 1) When a breakpoint location finds itself pointing to an Indirect symbol, when the site for it is created it needs to resolve the symbol and actually set the site at its target. 2) Not all breakpoints want to do this (i.e. a straight address breakpoint should always set itself on the specified address, so somem machinery was needed to specify that. 3) I added some info to the break list output for indirect symbols so you could see what was happening. Also I made it clear when we re-route through re-exported symbols. 4) I moved ResolveIndirectFunction from ProcessPosix to Process since it works the exact same way on Mac OS X and the other posix systems. If we find a platform that doesn't do it this way, they can override the call in Process. 5) Fixed one bug in RunThreadPlan, if you were trying to run a thread plan after a "running" event had been broadcast, the event coalescing would cause you to miss the ThreadPlan running event. So I added a way to override the coalescing. 6) Made DynamicLoaderMacOSXDYLD::GetStepThroughTrampolinePlan handle Indirect & Re-exported symbols. <rdar://problem/15280639> llvm-svn: 198976
2014-01-11 07:46:59 +08:00
// Forcing the next event delivery is a one shot deal. So reset it here.
m_force_next_event_delivery = 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
// 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.
sweep up -Wformat warnings from gcc This is a purely mechanical change explicitly casting any parameters for printf style conversion. This cleans up the warnings emitted by gcc 4.8 on Linux. llvm-svn: 205607
2014-04-04 12:06:10 +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 (return_value)
m_last_broadcast_state = state;
sweep up -Wformat warnings from gcc This is a purely mechanical change explicitly casting any parameters for printf style conversion. This cleans up the warnings emitted by gcc 4.8 on Linux. llvm-svn: 205607
2014-04-04 12:06:10 +08:00
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",
sweep up -Wformat warnings from gcc This is a purely mechanical change explicitly casting any parameters for printf style conversion. This cleans up the warnings emitted by gcc 4.8 on Linux. llvm-svn: 205607
2014-04-04 12:06:10 +08:00
static_cast<void*>(event_ptr), StateAsCString(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
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
Fix the handling of the run lock in cases where you needed to run a hand-called function from the private state thread. The problem was that on the way out of the private state thread, we try to drop the run lock. That is appropriate for the main private state thread, but not the secondary private state thread. Only the thread that spawned them can know whether this is an appropriate thing to do or not. <rdar://problem/21375352> llvm-svn: 240461
2015-06-24 05:02:45 +08:00
Process::StartPrivateStateThread (bool is_secondary_thread)
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");
Fix the handling of the run lock in cases where you needed to run a hand-called function from the private state thread. The problem was that on the way out of the private state thread, we try to drop the run lock. That is appropriate for the main private state thread, but not the secondary private state thread. Only the thread that spawned them can know whether this is an appropriate thing to do or not. <rdar://problem/21375352> llvm-svn: 240461
2015-06-24 05:02:45 +08:00
if (!is_secondary_thread && 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];
Add Host::MAX_THREAD_NAME_LENGTH constant. This value gets set to a max uint32_t value when there is no known limit; otherwise, it is set to a value appropriate for the platform. For the moment, only Linux, FreeBSD and NetBSD set it to 16. All other platforms set it to the max uint32_t value. Modifies the Process private state thread names to fit within a 16-character limit when the max thread name length is <= 16. These guarantee that the thread names can be distinguished within the first 16 characters. Prior to this change, those threads had names in the final dotted name segment that were not distinguishable within the first 16 characters. llvm-svn: 213183
2014-07-17 03:03:16 +08:00
Create a HostThread abstraction. This patch moves creates a thread abstraction that represents a thread running inside the LLDB process. This is a replacement for otherwise using lldb::thread_t, and provides a platform agnostic interface to managing these threads. Differential Revision: http://reviews.llvm.org/D5198 Reviewed by: Jim Ingham llvm-svn: 217460
2014-09-10 04:54:56 +08:00
if (HostInfo::GetMaxThreadNameLength() <= 30)
Add Host::MAX_THREAD_NAME_LENGTH constant. This value gets set to a max uint32_t value when there is no known limit; otherwise, it is set to a value appropriate for the platform. For the moment, only Linux, FreeBSD and NetBSD set it to 16. All other platforms set it to the max uint32_t value. Modifies the Process private state thread names to fit within a 16-character limit when the max thread name length is <= 16. These guarantee that the thread names can be distinguished within the first 16 characters. Prior to this change, those threads had names in the final dotted name segment that were not distinguishable within the first 16 characters. llvm-svn: 213183
2014-07-17 03:03:16 +08:00
{
Create a HostThread abstraction. This patch moves creates a thread abstraction that represents a thread running inside the LLDB process. This is a replacement for otherwise using lldb::thread_t, and provides a platform agnostic interface to managing these threads. Differential Revision: http://reviews.llvm.org/D5198 Reviewed by: Jim Ingham llvm-svn: 217460
2014-09-10 04:54:56 +08:00
// On platforms with abbreviated thread name lengths, choose thread names that fit within the limit.
if (already_running)
snprintf(thread_name, sizeof(thread_name), "intern-state-OV");
else
snprintf(thread_name, sizeof(thread_name), "intern-state");
Add Host::MAX_THREAD_NAME_LENGTH constant. This value gets set to a max uint32_t value when there is no known limit; otherwise, it is set to a value appropriate for the platform. For the moment, only Linux, FreeBSD and NetBSD set it to 16. All other platforms set it to the max uint32_t value. Modifies the Process private state thread names to fit within a 16-character limit when the max thread name length is <= 16. These guarantee that the thread names can be distinguished within the first 16 characters. Prior to this change, those threads had names in the final dotted name segment that were not distinguishable within the first 16 characters. llvm-svn: 213183
2014-07-17 03:03:16 +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
else
Add Host::MAX_THREAD_NAME_LENGTH constant. This value gets set to a max uint32_t value when there is no known limit; otherwise, it is set to a value appropriate for the platform. For the moment, only Linux, FreeBSD and NetBSD set it to 16. All other platforms set it to the max uint32_t value. Modifies the Process private state thread names to fit within a 16-character limit when the max thread name length is <= 16. These guarantee that the thread names can be distinguished within the first 16 characters. Prior to this change, those threads had names in the final dotted name segment that were not distinguishable within the first 16 characters. llvm-svn: 213183
2014-07-17 03:03:16 +08:00
{
if (already_running)
Create a HostThread abstraction. This patch moves creates a thread abstraction that represents a thread running inside the LLDB process. This is a replacement for otherwise using lldb::thread_t, and provides a platform agnostic interface to managing these threads. Differential Revision: http://reviews.llvm.org/D5198 Reviewed by: Jim Ingham llvm-svn: 217460
2014-09-10 04:54:56 +08:00
snprintf(thread_name, sizeof(thread_name), "<lldb.process.internal-state-override(pid=%" PRIu64 ")>", GetID());
Add Host::MAX_THREAD_NAME_LENGTH constant. This value gets set to a max uint32_t value when there is no known limit; otherwise, it is set to a value appropriate for the platform. For the moment, only Linux, FreeBSD and NetBSD set it to 16. All other platforms set it to the max uint32_t value. Modifies the Process private state thread names to fit within a 16-character limit when the max thread name length is <= 16. These guarantee that the thread names can be distinguished within the first 16 characters. Prior to this change, those threads had names in the final dotted name segment that were not distinguishable within the first 16 characters. llvm-svn: 213183
2014-07-17 03:03:16 +08:00
else
Create a HostThread abstraction. This patch moves creates a thread abstraction that represents a thread running inside the LLDB process. This is a replacement for otherwise using lldb::thread_t, and provides a platform agnostic interface to managing these threads. Differential Revision: http://reviews.llvm.org/D5198 Reviewed by: Jim Ingham llvm-svn: 217460
2014-09-10 04:54:56 +08:00
snprintf(thread_name, sizeof(thread_name), "<lldb.process.internal-state(pid=%" PRIu64 ")>", GetID());
Add Host::MAX_THREAD_NAME_LENGTH constant. This value gets set to a max uint32_t value when there is no known limit; otherwise, it is set to a value appropriate for the platform. For the moment, only Linux, FreeBSD and NetBSD set it to 16. All other platforms set it to the max uint32_t value. Modifies the Process private state thread names to fit within a 16-character limit when the max thread name length is <= 16. These guarantee that the thread names can be distinguished within the first 16 characters. Prior to this change, those threads had names in the final dotted name segment that were not distinguishable within the first 16 characters. llvm-svn: 213183
2014-07-17 03:03:16 +08:00
}
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.
Fix the handling of the run lock in cases where you needed to run a hand-called function from the private state thread. The problem was that on the way out of the private state thread, we try to drop the run lock. That is appropriate for the main private state thread, but not the secondary private state thread. Only the thread that spawned them can know whether this is an appropriate thing to do or not. <rdar://problem/21375352> llvm-svn: 240461
2015-06-24 05:02:45 +08:00
PrivateStateThreadArgs args = {this, is_secondary_thread};
Set the minimum stack size for private state thread to 8MB Demangling complex Boost symbols can exhaust the default stack size. In practice, any thread that calls into LLDB functionality that touches symbols runs this risk. Guaranteeing a reasonable minimum for our own private state thread addressees some known scenarios debugging processes that make use of cpp-netlib. llvm-svn: 255868
2015-12-17 09:37:00 +08:00
m_private_state_thread = ThreadLauncher::LaunchThread(thread_name, Process::PrivateStateThread, (void *) &args, NULL, 8 * 1024 * 1024);
Fix up the HostThread interface, making the interface simpler. Reviewed by: Greg Clayton Differential Revision: http://reviews.llvm.org/D5417 llvm-svn: 218325
2014-09-24 02:32:09 +08:00
if (m_private_state_thread.IsJoinable())
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
{
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
Create a HostThread abstraction. This patch moves creates a thread abstraction that represents a thread running inside the LLDB process. This is a replacement for otherwise using lldb::thread_t, and provides a platform agnostic interface to managing these threads. Differential Revision: http://reviews.llvm.org/D5198 Reviewed by: Jim Ingham llvm-svn: 217460
2014-09-10 04:54:56 +08:00
HostThread private_state_thread(m_private_state_thread);
Fix up the HostThread interface, making the interface simpler. Reviewed by: Greg Clayton Differential Revision: http://reviews.llvm.org/D5417 llvm-svn: 218325
2014-09-24 02:32:09 +08:00
if (private_state_thread.IsJoinable())
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
{
Create a HostThread abstraction. This patch moves creates a thread abstraction that represents a thread running inside the LLDB process. This is a replacement for otherwise using lldb::thread_t, and provides a platform agnostic interface to managing these threads. Differential Revision: http://reviews.llvm.org/D5198 Reviewed by: Jim Ingham llvm-svn: 217460
2014-09-10 04:54:56 +08:00
Error error = private_state_thread.Cancel();
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 ("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;
Create a HostThread abstraction. This patch moves creates a thread abstraction that represents a thread running inside the LLDB process. This is a replacement for otherwise using lldb::thread_t, and provides a platform agnostic interface to managing these threads. Differential Revision: http://reviews.llvm.org/D5198 Reviewed by: Jim Ingham llvm-svn: 217460
2014-09-10 04:54:56 +08:00
private_state_thread.Join(&result);
m_private_state_thread.Reset();
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));
Figure out the reply to "PlanExplainsStop" once when we stop and then use the cached value. This fixes problems, for instance, with the StepRange plans, where they know that they explained the stop because they were at their "run to here" breakpoint, then deleted that breakpoint, so when they got asked again, doh! I had done this for a couple of plans in an ad hoc fashion, this just formalizes it. Also add a "ResumeRequested" in Process so that the code in the completion handlers can tell the ShouldStop logic they want to resume rather than just directly resuming. That allows us to handle resuming in a more controlled fashion. Also, SetPublicState can take a "restarted" flag, so that it doesn't drop the run lock when the target was immediately restarted. --This line, and those below , will be ignored-- M test/lang/objc/objc-dynamic-value/TestObjCDynamicValue.py M include/lldb/Target/ThreadList.h M include/lldb/Target/ThreadPlanStepOut.h M include/lldb/Target/Thread.h M include/lldb/Target/ThreadPlanBase.h M include/lldb/Target/ThreadPlanStepThrough.h M include/lldb/Target/ThreadPlanStepInstruction.h M include/lldb/Target/ThreadPlanStepInRange.h M include/lldb/Target/ThreadPlanStepOverBreakpoint.h M include/lldb/Target/ThreadPlanStepUntil.h M include/lldb/Target/StopInfo.h M include/lldb/Target/Process.h M include/lldb/Target/ThreadPlanRunToAddress.h M include/lldb/Target/ThreadPlan.h M include/lldb/Target/ThreadPlanCallFunction.h M include/lldb/Target/ThreadPlanStepOverRange.h M source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleThreadPlanStepThroughObjCTrampoline.h M source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleThreadPlanStepThroughObjCTrampoline.cpp M source/Target/StopInfo.cpp M source/Target/Process.cpp M source/Target/ThreadPlanRunToAddress.cpp M source/Target/ThreadPlan.cpp M source/Target/ThreadPlanCallFunction.cpp M source/Target/ThreadPlanStepOverRange.cpp M source/Target/ThreadList.cpp M source/Target/ThreadPlanStepOut.cpp M source/Target/Thread.cpp M source/Target/ThreadPlanBase.cpp M source/Target/ThreadPlanStepThrough.cpp M source/Target/ThreadPlanStepInstruction.cpp M source/Target/ThreadPlanStepInRange.cpp M source/Target/ThreadPlanStepOverBreakpoint.cpp M source/Target/ThreadPlanStepUntil.cpp M lldb.xcodeproj/xcshareddata/xcschemes/Run Testsuite.xcscheme llvm-svn: 181381
2013-05-08 08:35:16 +08:00
m_resume_requested = false;
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)
{
Fixed all overlapping prompt issues. I carefully reviewed exactly how the IOHandlers interact and found places where we weren't properly controlling things. There should be no overlapping prompts and all output should now come out in a controlled fashion. <rdar://problem/16111293> llvm-svn: 202525
2014-03-01 02:22:24 +08:00
const bool is_hijacked = IsHijackedForEvent(eBroadcastBitStateChanged);
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 (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 ()),
Fixed all overlapping prompt issues. I carefully reviewed exactly how the IOHandlers interact and found places where we weren't properly controlling things. There should be no overlapping prompts and all output should now come out in a controlled fashion. <rdar://problem/16111293> llvm-svn: 202525
2014-03-01 02:22:24 +08:00
is_hijacked ? "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))
Merging the iohandler branch back into main. The many many benefits include: 1 - Input/Output/Error streams are now handled as real streams not a push style input 2 - auto completion in python embedded interpreter 3 - multi-line input for "script" and "expression" commands now allow you to edit previous/next lines using up and down arrow keys and this makes multi-line input actually a viable thing to use 4 - it is now possible to use curses to drive LLDB (please try the "gui" command) We will need to deal with and fix any buildbot failures and tests and arise now that input/output and error are correctly hooked up in all cases. llvm-svn: 200263
2014-01-28 07:43:24 +08:00
{
// Only push the input handler if we aren't fowarding events,
// as this means the curses GUI is in use...
Fix spurious output to command line when launching a process on Linux. See http://reviews.llvm.org/D5632 for details. Change by Shawn Best. llvm-svn: 219213
2014-10-08 00:05:21 +08:00
// Or don't push it if we are launching since it will come up stopped.
Implement attach to process on Windows. Differential Revision: http://reviews.llvm.org/D9801 Reviewed by: Adrian McCarthy llvm-svn: 237817
2015-05-21 02:31:17 +08:00
if (!GetTarget().GetDebugger().IsForwardingEvents() && new_state != eStateLaunching &&
new_state != eStateAttaching)
Improve LLDB prompt handling Summary: There is an issue in lldb where the command prompt can appear at the wrong time. The partial fix we have in for this is not working all the time and is introducing unnecessary delays. This change does: - Change Process:SyncIOHandler to use integer start id's for synchronization to avoid it being confused by quick start-stop cycles. I picked this up from a suggested patch by Greg to lldb-dev. - coordinates printing of asynchronous text with the iohandlers. This is also based on a (different) Greg's patch, but I have added stronger synchronization to it to avoid races. Together, these changes solve the prompt problem for me on linux (both with and without libedit). I think they should behave similarly on Mac and FreeBSD and I think they will not make matters worse for windows. Test Plan: Prompt comes out alright. All tests still pass on linux. Reviewers: clayborg, emaste, zturner Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D9823 llvm-svn: 238313
2015-05-27 20:40:32 +08:00
{
Merging the iohandler branch back into main. The many many benefits include: 1 - Input/Output/Error streams are now handled as real streams not a push style input 2 - auto completion in python embedded interpreter 3 - multi-line input for "script" and "expression" commands now allow you to edit previous/next lines using up and down arrow keys and this makes multi-line input actually a viable thing to use 4 - it is now possible to use curses to drive LLDB (please try the "gui" command) We will need to deal with and fix any buildbot failures and tests and arise now that input/output and error are correctly hooked up in all cases. llvm-svn: 200263
2014-01-28 07:43:24 +08:00
PushProcessIOHandler ();
Improve LLDB prompt handling Summary: There is an issue in lldb where the command prompt can appear at the wrong time. The partial fix we have in for this is not working all the time and is introducing unnecessary delays. This change does: - Change Process:SyncIOHandler to use integer start id's for synchronization to avoid it being confused by quick start-stop cycles. I picked this up from a suggested patch by Greg to lldb-dev. - coordinates printing of asynchronous text with the iohandlers. This is also based on a (different) Greg's patch, but I have added stronger synchronization to it to avoid races. Together, these changes solve the prompt problem for me on linux (both with and without libedit). I think they should behave similarly on Mac and FreeBSD and I think they will not make matters worse for windows. Test Plan: Prompt comes out alright. All tests still pass on linux. Reviewers: clayborg, emaste, zturner Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D9823 llvm-svn: 238313
2015-05-27 20:40:32 +08:00
m_iohandler_sync.SetValue(m_iohandler_sync.GetValue()+1, eBroadcastAlways);
if (log)
log->Printf("Process::%s updated m_iohandler_sync to %d", __FUNCTION__, m_iohandler_sync.GetValue());
}
Merging the iohandler branch back into main. The many many benefits include: 1 - Input/Output/Error streams are now handled as real streams not a push style input 2 - auto completion in python embedded interpreter 3 - multi-line input for "script" and "expression" commands now allow you to edit previous/next lines using up and down arrow keys and this makes multi-line input actually a viable thing to use 4 - it is now possible to use curses to drive LLDB (please try the "gui" command) We will need to deal with and fix any buildbot failures and tests and arise now that input/output and error are correctly hooked up in all cases. llvm-svn: 200263
2014-01-28 07:43:24 +08:00
}
Fixed all overlapping prompt issues. I carefully reviewed exactly how the IOHandlers interact and found places where we weren't properly controlling things. There should be no overlapping prompts and all output should now come out in a controlled fashion. <rdar://problem/16111293> llvm-svn: 202525
2014-03-01 02:22:24 +08:00
else if (StateIsStoppedState(new_state, false))
{
if (!Process::ProcessEventData::GetRestartedFromEvent(event_sp.get()))
{
// If the lldb_private::Debugger is handling the events, we don't
// want to pop the process IOHandler here, we want to do it when
// we receive the stopped event so we can carefully control when
// the process IOHandler is popped because when we stop we want to
// display some text stating how and why we stopped, then maybe some
// process/thread/frame info, and then we want the "(lldb) " prompt
// to show up. If we pop the process IOHandler here, then we will
// cause the command interpreter to become the top IOHandler after
// the process pops off and it will update its prompt right away...
// See the Debugger.cpp file where it calls the function as
// "process_sp->PopProcessIOHandler()" to see where I am talking about.
// Otherwise we end up getting overlapping "(lldb) " prompts and
// garbled output.
//
// If we aren't handling the events in the debugger (which is indicated
// by "m_target.GetDebugger().IsHandlingEvents()" returning false) or we
// are hijacked, then we always pop the process IO handler manually.
// Hijacking happens when the internal process state thread is running
// thread plans, or when commands want to run in synchronous mode
// and they call "process->WaitForProcessToStop()". An example of something
// that will hijack the events is a simple expression:
//
// (lldb) expr (int)puts("hello")
//
// This will cause the internal process state thread to resume and halt
// the process (and _it_ will hijack the eBroadcastBitStateChanged
// events) and we do need the IO handler to be pushed and popped
// correctly.
Have the Process hold a weak_ptr to the Target. llvm-svn: 246578
2015-09-02 04:02:29 +08:00
if (is_hijacked || GetTarget().GetDebugger().IsHandlingEvents() == false)
Fixed all overlapping prompt issues. I carefully reviewed exactly how the IOHandlers interact and found places where we weren't properly controlling things. There should be no overlapping prompts and all output should now come out in a controlled fashion. <rdar://problem/16111293> llvm-svn: 202525
2014-03-01 02:22:24 +08:00
PopProcessIOHandler ();
}
}
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
}
}
Recommit "Fix race during process interruption" This is a resubmit of r254403, see that commit's message for context. This fixes an issue in the original commit, where we would incorrectly interrupt the process if the interrupt request came just as we were about to send the stopped event to the public. llvm-svn: 254902
2015-12-07 20:36:52 +08:00
}
Error
Process::HaltPrivate()
{
EventSP event_sp;
Error error (WillHalt());
if (error.Fail())
return error;
// Ask the process subclass to actually halt our process
bool caused_stop;
error = DoHalt(caused_stop);
DidHalt();
return error;
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
MingW compilation (windows). Includes various refactoring to improve portability. llvm-svn: 189107
2013-08-23 20:44:05 +08:00
thread_result_t
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
Process::PrivateStateThread (void *arg)
{
Fix the handling of the run lock in cases where you needed to run a hand-called function from the private state thread. The problem was that on the way out of the private state thread, we try to drop the run lock. That is appropriate for the main private state thread, but not the secondary private state thread. Only the thread that spawned them can know whether this is an appropriate thing to do or not. <rdar://problem/21375352> llvm-svn: 240461
2015-06-24 05:02:45 +08:00
PrivateStateThreadArgs *real_args = static_cast<PrivateStateThreadArgs *> (arg);
thread_result_t result = real_args->process->RunPrivateStateThread(real_args->is_secondary_thread);
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
return result;
}
MingW compilation (windows). Includes various refactoring to improve portability. llvm-svn: 189107
2013-08-23 20:44:05 +08:00
thread_result_t
Fix the handling of the run lock in cases where you needed to run a hand-called function from the private state thread. The problem was that on the way out of the private state thread, we try to drop the run lock. That is appropriate for the main private state thread, but not the secondary private state thread. Only the thread that spawned them can know whether this is an appropriate thing to do or not. <rdar://problem/21375352> llvm-svn: 240461
2015-06-24 05:02:45 +08:00
Process::RunPrivateStateThread (bool is_secondary_thread)
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
{
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)
sweep up -Wformat warnings from gcc This is a purely mechanical change explicitly casting any parameters for printf style conversion. This cleans up the warnings emitted by gcc 4.8 on Linux. llvm-svn: 205607
2014-04-04 12:06:10 +08:00
log->Printf ("Process::%s (arg = %p, pid = %" PRIu64 ") thread starting...",
__FUNCTION__, static_cast<void*>(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;
Recommit "Fix race during process interruption" This is a resubmit of r254403, see that commit's message for context. This fixes an issue in the original commit, where we would incorrectly interrupt the process if the interrupt request came just as we were about to send the stopped event to the public. llvm-svn: 254902
2015-12-07 20:36:52 +08:00
bool interrupt_requested = false;
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
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)
sweep up -Wformat warnings from gcc This is a purely mechanical change explicitly casting any parameters for printf style conversion. This cleans up the warnings emitted by gcc 4.8 on Linux. llvm-svn: 205607
2014-04-04 12:06:10 +08:00
log->Printf ("Process::%s (arg = %p, pid = %" PRIu64 ") got a control event: %d",
__FUNCTION__, static_cast<void*>(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;
Fix typos. llvm-svn: 212132
2014-07-02 05:22:11 +08:00
break; // doing any internal state management below
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
case eBroadcastInternalStateControlPause:
control_only = true;
break;
case eBroadcastInternalStateControlResume:
control_only = false;
break;
}
sweep up -Wformat warnings from gcc This is a purely mechanical change explicitly casting any parameters for printf style conversion. This cleans up the warnings emitted by gcc 4.8 on Linux. llvm-svn: 205607
2014-04-04 12:06:10 +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)
sweep up -Wformat warnings from gcc This is a purely mechanical change explicitly casting any parameters for printf style conversion. This cleans up the warnings emitted by gcc 4.8 on Linux. llvm-svn: 205607
2014-04-04 12:06:10 +08:00
log->Printf ("Process::%s (arg = %p, pid = %" PRIu64 ") woke up with an interrupt while attaching - forwarding interrupt.",
__FUNCTION__, static_cast<void*>(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);
}
Recommit "Fix race during process interruption" This is a resubmit of r254403, see that commit's message for context. This fixes an issue in the original commit, where we would incorrectly interrupt the process if the interrupt request came just as we were about to send the stopped event to the public. llvm-svn: 254902
2015-12-07 20:36:52 +08:00
else if(StateIsRunningState(m_last_broadcast_state))
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)
sweep up -Wformat warnings from gcc This is a purely mechanical change explicitly casting any parameters for printf style conversion. This cleans up the warnings emitted by gcc 4.8 on Linux. llvm-svn: 205607
2014-04-04 12:06:10 +08:00
log->Printf ("Process::%s (arg = %p, pid = %" PRIu64 ") woke up with an interrupt - Halting.",
__FUNCTION__, static_cast<void*>(this),
GetID());
Recommit "Fix race during process interruption" This is a resubmit of r254403, see that commit's message for context. This fixes an issue in the original commit, where we would incorrectly interrupt the process if the interrupt request came just as we were about to send the stopped event to the public. llvm-svn: 254902
2015-12-07 20:36:52 +08:00
Error error = HaltPrivate();
if (error.Fail() && log)
log->Printf ("Process::%s (arg = %p, pid = %" PRIu64 ") failed to halt the process: %s",
__FUNCTION__, static_cast<void*>(this),
GetID(), error.AsCString());
// Halt should generate a stopped event. Make a note of the fact that we were
// doing the interrupt, so we can set the interrupted flag after we receive the
// event. We deliberately set this to true even if HaltPrivate failed, so that we
// can interrupt on the next natural stop.
interrupt_requested = true;
}
else
{
// This can happen when someone (e.g. Process::Halt) sees that we are running and
// sends an interrupt request, but the process actually stops before we receive
// it. In that case, we can just ignore the request. We use
// m_last_broadcast_state, because the Stopped event may not have been popped of
// the event queue yet, which is when the public state gets updated.
if (log)
log->Printf("Process::%s ignoring interrupt as we have already stopped.", __FUNCTION__);
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
}
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)
{
<rdar://problem/13700260> Avoid a deadlock when using the OperatingSystemPython code and typing "process interrupt". There was a possible lock inversion between the target API lock and the process' thread list lock due to code trying to discard the thread list. This was fixed by adding a boolean to Process::Halt() that indicates if the thread plans should be discarded and doing it in the private state thread when we process the stopped state. llvm-svn: 181651
2013-05-11 07:48:10 +08:00
if (m_clear_thread_plans_on_stop &&
StateIsStoppedState(internal_state, true))
{
m_clear_thread_plans_on_stop = false;
m_thread_list.DiscardThreadPlans();
}
Recommit "Fix race during process interruption" This is a resubmit of r254403, see that commit's message for context. This fixes an issue in the original commit, where we would incorrectly interrupt the process if the interrupt request came just as we were about to send the stopped event to the public. llvm-svn: 254902
2015-12-07 20:36:52 +08:00
if (interrupt_requested)
{
if (StateIsStoppedState (internal_state, true))
{
// We requested the interrupt, 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);
interrupt_requested = false;
}
else if (log)
{
log->Printf("Process::%s interrupt_requested, but a non-stopped state '%s' received.",
__FUNCTION__, StateAsCString(internal_state));
}
}
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
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)
sweep up -Wformat warnings from gcc This is a purely mechanical change explicitly casting any parameters for printf style conversion. This cleans up the warnings emitted by gcc 4.8 on Linux. llvm-svn: 205607
2014-04-04 12:06:10 +08:00
log->Printf ("Process::%s (arg = %p, pid = %" PRIu64 ") about to exit with internal state %s...",
__FUNCTION__, static_cast<void*>(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)
sweep up -Wformat warnings from gcc This is a purely mechanical change explicitly casting any parameters for printf style conversion. This cleans up the warnings emitted by gcc 4.8 on Linux. llvm-svn: 205607
2014-04-04 12:06:10 +08:00
log->Printf ("Process::%s (arg = %p, pid = %" PRIu64 ") thread exiting...",
__FUNCTION__, static_cast<void*>(this), GetID());
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
Fix the handling of the run lock in cases where you needed to run a hand-called function from the private state thread. The problem was that on the way out of the private state thread, we try to drop the run lock. That is appropriate for the main private state thread, but not the secondary private state thread. Only the thread that spawned them can know whether this is an appropriate thing to do or not. <rdar://problem/21375352> llvm-svn: 240461
2015-06-24 05:02:45 +08:00
// If we are a secondary thread, then the primary thread we are working for will have already
// acquired the public_run_lock, and isn't done with what it was doing yet, so don't
// try to change it on the way out.
if (!is_secondary_thread)
m_public_run_lock.SetStopped();
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);
Create a HostThread abstraction. This patch moves creates a thread abstraction that represents a thread running inside the LLDB process. This is a replacement for otherwise using lldb::thread_t, and provides a platform agnostic interface to managing these threads. Differential Revision: http://reviews.llvm.org/D5198 Reviewed by: Jim Ingham llvm-svn: 217460
2014-09-10 04:54:56 +08:00
m_private_state_thread.Reset();
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 (),
Change ProcessEventData over to use a std::weak_ptr to a process intead of a std::shared_ptr. Anyone consuming events for a process should have the process around long enough to grab the event and anyone that holds onto an event for too long won't keep the process around. llvm-svn: 238541
2015-05-29 11:20:37 +08:00
m_process_wp (),
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
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 (),
Change ProcessEventData over to use a std::weak_ptr to a process intead of a std::shared_ptr. Anyone consuming events for a process should have the process around long enough to grab the event and anyone that holds onto an event for too long won't keep the process around. llvm-svn: 238541
2015-05-29 11:20:37 +08:00
m_process_wp (),
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
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
{
Change ProcessEventData over to use a std::weak_ptr to a process intead of a std::shared_ptr. Anyone consuming events for a process should have the process around long enough to grab the event and anyone that holds onto an event for too long won't keep the process around. llvm-svn: 238541
2015-05-29 11:20:37 +08:00
if (process_sp)
m_process_wp = process_sp;
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
Fix Clang-tidy modernize-use-override warnings in source/Target; other minor fixes. llvm-svn: 251134
2015-10-24 02:39:37 +08:00
Process::ProcessEventData::~ProcessEventData() = default;
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
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)
{
Change ProcessEventData over to use a std::weak_ptr to a process intead of a std::shared_ptr. Anyone consuming events for a process should have the process around long enough to grab the event and anyone that holds onto an event for too long won't keep the process around. llvm-svn: 238541
2015-05-29 11:20:37 +08:00
ProcessSP process_sp(m_process_wp.lock());
if (!process_sp)
return;
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
// 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,
Figure out the reply to "PlanExplainsStop" once when we stop and then use the cached value. This fixes problems, for instance, with the StepRange plans, where they know that they explained the stop because they were at their "run to here" breakpoint, then deleted that breakpoint, so when they got asked again, doh! I had done this for a couple of plans in an ad hoc fashion, this just formalizes it. Also add a "ResumeRequested" in Process so that the code in the completion handlers can tell the ShouldStop logic they want to resume rather than just directly resuming. That allows us to handle resuming in a more controlled fashion. Also, SetPublicState can take a "restarted" flag, so that it doesn't drop the run lock when the target was immediately restarted. --This line, and those below , will be ignored-- M test/lang/objc/objc-dynamic-value/TestObjCDynamicValue.py M include/lldb/Target/ThreadList.h M include/lldb/Target/ThreadPlanStepOut.h M include/lldb/Target/Thread.h M include/lldb/Target/ThreadPlanBase.h M include/lldb/Target/ThreadPlanStepThrough.h M include/lldb/Target/ThreadPlanStepInstruction.h M include/lldb/Target/ThreadPlanStepInRange.h M include/lldb/Target/ThreadPlanStepOverBreakpoint.h M include/lldb/Target/ThreadPlanStepUntil.h M include/lldb/Target/StopInfo.h M include/lldb/Target/Process.h M include/lldb/Target/ThreadPlanRunToAddress.h M include/lldb/Target/ThreadPlan.h M include/lldb/Target/ThreadPlanCallFunction.h M include/lldb/Target/ThreadPlanStepOverRange.h M source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleThreadPlanStepThroughObjCTrampoline.h M source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleThreadPlanStepThroughObjCTrampoline.cpp M source/Target/StopInfo.cpp M source/Target/Process.cpp M source/Target/ThreadPlanRunToAddress.cpp M source/Target/ThreadPlan.cpp M source/Target/ThreadPlanCallFunction.cpp M source/Target/ThreadPlanStepOverRange.cpp M source/Target/ThreadList.cpp M source/Target/ThreadPlanStepOut.cpp M source/Target/Thread.cpp M source/Target/ThreadPlanBase.cpp M source/Target/ThreadPlanStepThrough.cpp M source/Target/ThreadPlanStepInstruction.cpp M source/Target/ThreadPlanStepInRange.cpp M source/Target/ThreadPlanStepOverBreakpoint.cpp M source/Target/ThreadPlanStepUntil.cpp M lldb.xcodeproj/xcshareddata/xcschemes/Run Testsuite.xcscheme llvm-svn: 181381
2013-05-08 08:35:16 +08:00
// and > 1 for expression evaluation, and we don't want to do the breakpoint command handling then.
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
Change ProcessEventData over to use a std::weak_ptr to a process intead of a std::shared_ptr. Anyone consuming events for a process should have the process around long enough to grab the event and anyone that holds onto an event for too long won't keep the process around. llvm-svn: 238541
2015-05-29 11:20:37 +08:00
process_sp->SetPublicState (m_state, Process::ProcessEventData::GetRestartedFromEvent(event_ptr));
Fix the behavior when hand-calling a function times out on one thread, but by the time we go to halt, it has already stopped by hitting the function end breakpoint. That wasn't being shown to the threads so the Function call thread plan didn't know its job was done. <rdar://problem/16515785> llvm-svn: 205803
2014-04-09 05:33:21 +08:00
// If this is a halt event, even if the halt stopped with some reason other than a plain interrupt (e.g. we had
// already stopped for a breakpoint when the halt request came through) don't do the StopInfo actions, as they may
// end up restarting the process.
if (m_interrupted)
return;
// If we're stopped and haven't restarted, then do the StopInfo actions here:
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
if (m_state == eStateStopped && ! m_restarted)
More packet performance improvements. Changed the "jthreads" key/value in the stop reply packets to be "jstopinfo". This JSON only contains threads with valid stop reasons and allows us not to have to ask about other threads via qThreadStopInfo when we are stepping. The "jstopinfo" only gets sent if there are more than one thread since the stop reply packet contains all the info needed for a single thread. Added a Process::WillPublicStop() in case process subclasses want to do any extra gathering for public stops. For ProcessGDBRemote, we end up sending a jThreadsInfo packet to gather all expedited registers, expedited memory and MacOSX queue information. We only do this for public stops to minimize the packets we send when we have multiple private stops. Multiple private stops happen when a source level single step, step into or step out run the process multiple times while implementing the stepping, and none of these private stops make it out to the UI via notifications because they are private stops. llvm-svn: 242593
2015-07-18 07:42:28 +08:00
{
// Let process subclasses know we are about to do a public stop and
// do anything they might need to in order to speed up register and
// memory accesses.
process_sp->WillPublicStop();
Change ProcessEventData over to use a std::weak_ptr to a process intead of a std::shared_ptr. Anyone consuming events for a process should have the process around long enough to grab the event and anyone that holds onto an event for too long won't keep the process around. llvm-svn: 238541
2015-05-29 11:20:37 +08:00
ThreadList &curr_thread_list = 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
In Process::ProcessEventData::DoOnRemoval, we need to handle the case where NO thread has a stop reason specially, and make sure we stop. This shouldn't happen, but if it does, the user will probably want to see it. <rdar://problem/13273125> llvm-svn: 180244
2013-04-25 10:04:59 +08:00
// Sometimes - for instance if we have a bug in the stub we are talking to, we stop but no thread has a
// valid stop reason. In that case we should just stop, because we have no way of telling what the right
// thing to do is, and it's better to let the user decide than continue behind their backs.
bool does_anybody_have_an_opinion = false;
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)
{
Change ProcessEventData over to use a std::weak_ptr to a process intead of a std::shared_ptr. Anyone consuming events for a process should have the process around long enough to grab the event and anyone that holds onto an event for too long won't keep the process around. llvm-svn: 238541
2015-05-29 11:20:37 +08:00
curr_thread_list = process_sp->GetThreadList();
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
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
{
In Process::ProcessEventData::DoOnRemoval, we need to handle the case where NO thread has a stop reason specially, and make sure we stop. This shouldn't happen, but if it does, the user will probably want to see it. <rdar://problem/13273125> llvm-svn: 180244
2013-04-25 10:04:59 +08:00
does_anybody_have_an_opinion = true;
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
}
}
Revert of r179378 and r179329, which introduce a private thread lock around thread enumeration, in order to prevent consistent hangs on all 3 LLDB buildbots. llvm-svn: 179759
2013-04-18 22:38:20 +08:00
Don't check the private state in DoOnRemoval, check whether THIS event caused a restart. rdar://problem/13788593 llvm-svn: 181068
2013-05-04 07:04:37 +08:00
if (!GetRestarted())
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
{
In Process::ProcessEventData::DoOnRemoval, we need to handle the case where NO thread has a stop reason specially, and make sure we stop. This shouldn't happen, but if it does, the user will probably want to see it. <rdar://problem/13273125> llvm-svn: 180244
2013-04-25 10:04:59 +08:00
if (!still_should_stop && does_anybody_have_an_opinion)
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'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.
Change ProcessEventData over to use a std::weak_ptr to a process intead of a std::shared_ptr. Anyone consuming events for a process should have the process around long enough to grab the event and anyone that holds onto an event for too long won't keep the process around. llvm-svn: 238541
2015-05-29 11:20:37 +08:00
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.
Change ProcessEventData over to use a std::weak_ptr to a process intead of a std::shared_ptr. Anyone consuming events for a process should have the process around long enough to grab the event and anyone that holds onto an event for too long won't keep the process around. llvm-svn: 238541
2015-05-29 11:20:37 +08:00
process_sp->GetTarget().RunStopHooks();
if (process_sp->GetPrivateState() == eStateRunning)
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
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
{
Change ProcessEventData over to use a std::weak_ptr to a process intead of a std::shared_ptr. Anyone consuming events for a process should have the process around long enough to grab the event and anyone that holds onto an event for too long won't keep the process around. llvm-svn: 238541
2015-05-29 11:20:37 +08:00
ProcessSP process_sp(m_process_wp.lock());
if (process_sp)
sweep up -Wformat warnings from gcc This is a purely mechanical change explicitly casting any parameters for printf style conversion. This cleans up the warnings emitted by gcc 4.8 on Linux. llvm-svn: 205607
2014-04-04 12:06:10 +08:00
s->Printf(" process = %p (pid = %" PRIu64 "), ",
Change ProcessEventData over to use a std::weak_ptr to a process intead of a std::shared_ptr. Anyone consuming events for a process should have the process around long enough to grab the event and anyone that holds onto an event for too long won't keep the process around. llvm-svn: 238541
2015-05-29 11:20:37 +08:00
static_cast<void*>(process_sp.get()), process_sp->GetID());
else
s->PutCString(" process = NULL, ");
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 ()
{
Have the Process hold a weak_ptr to the Target. llvm-svn: 246578
2015-09-02 04:02:29 +08:00
return m_target_sp.lock();
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
}
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
{
Have the Process hold a weak_ptr to the Target. llvm-svn: 246578
2015-09-02 04:02:29 +08:00
exe_ctx.SetTargetPtr (&GetTarget());
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.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
<rdar://problem/14182286> Made sure that temporary object created from HarmonizeThreadIdsForProfileData() doesn’t get passed around without creating an object first. Reviewed by Greg llvm-svn: 184769
2013-06-25 02:15:05 +08:00
Process::BroadcastAsyncProfileData(const std::string &one_profile_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
{
Mutex::Locker locker (m_profile_data_comm_mutex);
<rdar://problem/14182286> Made sure that temporary object created from HarmonizeThreadIdsForProfileData() doesn’t get passed around without creating an object first. Reviewed by Greg llvm-svn: 184769
2013-06-25 02:15:05 +08:00
m_profile_data.push_back(one_profile_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
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;
<rdar://problem/14182286> Made sure that temporary object created from HarmonizeThreadIdsForProfileData() doesn’t get passed around without creating an object first. Reviewed by Greg llvm-svn: 184769
2013-06-25 02:15:05 +08:00
std::string &one_profile_data = m_profile_data.front();
size_t bytes_available = one_profile_data.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)
sweep up -Wformat warnings from gcc This is a purely mechanical change explicitly casting any parameters for printf style conversion. This cleans up the warnings emitted by gcc 4.8 on Linux. llvm-svn: 205607
2014-04-04 12:06:10 +08:00
log->Printf ("Process::GetProfileData (buf = %p, size = %" PRIu64 ")",
static_cast<void*>(buf),
static_cast<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/14182286> Made sure that temporary object created from HarmonizeThreadIdsForProfileData() doesn’t get passed around without creating an object first. Reviewed by Greg llvm-svn: 184769
2013-06-25 02:15:05 +08:00
memcpy(buf, one_profile_data.c_str(), buf_size);
one_profile_data.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/14182286> Made sure that temporary object created from HarmonizeThreadIdsForProfileData() doesn’t get passed around without creating an object first. Reviewed by Greg llvm-svn: 184769
2013-06-25 02:15:05 +08:00
memcpy(buf, one_profile_data.c_str(), bytes_available);
<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.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)
sweep up -Wformat warnings from gcc This is a purely mechanical change explicitly casting any parameters for printf style conversion. This cleans up the warnings emitted by gcc 4.8 on Linux. llvm-svn: 205607
2014-04-04 12:06:10 +08:00
log->Printf ("Process::GetSTDOUT (buf = %p, size = %" PRIu64 ")",
static_cast<void*>(buf),
static_cast<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)
sweep up -Wformat warnings from gcc This is a purely mechanical change explicitly casting any parameters for printf style conversion. This cleans up the warnings emitted by gcc 4.8 on Linux. llvm-svn: 205607
2014-04-04 12:06:10 +08:00
log->Printf ("Process::GetSTDERR (buf = %p, size = %" PRIu64 ")",
static_cast<void*>(buf),
static_cast<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);
}
Merging the iohandler branch back into main. The many many benefits include: 1 - Input/Output/Error streams are now handled as real streams not a push style input 2 - auto completion in python embedded interpreter 3 - multi-line input for "script" and "expression" commands now allow you to edit previous/next lines using up and down arrow keys and this makes multi-line input actually a viable thing to use 4 - it is now possible to use curses to drive LLDB (please try the "gui" command) We will need to deal with and fix any buildbot failures and tests and arise now that input/output and error are correctly hooked up in all cases. llvm-svn: 200263
2014-01-28 07:43:24 +08:00
class IOHandlerProcessSTDIO :
public IOHandler
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
{
Merging the iohandler branch back into main. The many many benefits include: 1 - Input/Output/Error streams are now handled as real streams not a push style input 2 - auto completion in python embedded interpreter 3 - multi-line input for "script" and "expression" commands now allow you to edit previous/next lines using up and down arrow keys and this makes multi-line input actually a viable thing to use 4 - it is now possible to use curses to drive LLDB (please try the "gui" command) We will need to deal with and fix any buildbot failures and tests and arise now that input/output and error are correctly hooked up in all cases. llvm-svn: 200263
2014-01-28 07:43:24 +08:00
public:
IOHandlerProcessSTDIO (Process *process,
int write_fd) :
Complete rewrite of interactive editing support for single- and multi-line input. Improvements include: * Use of libedit's wide character support, which is imperfect but a distinct improvement over ASCII-only * Fallback for ASCII editing path * Support for a "faint" prompt clearly distinguished from input * Breaking lines and insert new lines in the middle of a batch by simply pressing return * Joining lines with forward and backward character deletion * Detection of paste to suppress automatic formatting and statement completion tests * Correctly reformatting when lines grow or shrink to occupy different numbers of rows * Saving multi-line history, and correctly preserving the "tip" of history during editing * Displaying visible ^C and ^D indications when interrupting input or sending EOF * Fledgling VI support for multi-line editing * General correctness and reliability improvements llvm-svn: 222163
2014-11-18 03:06:59 +08:00
IOHandler(process->GetTarget().GetDebugger(), IOHandler::Type::ProcessIO),
Merging the iohandler branch back into main. The many many benefits include: 1 - Input/Output/Error streams are now handled as real streams not a push style input 2 - auto completion in python embedded interpreter 3 - multi-line input for "script" and "expression" commands now allow you to edit previous/next lines using up and down arrow keys and this makes multi-line input actually a viable thing to use 4 - it is now possible to use curses to drive LLDB (please try the "gui" command) We will need to deal with and fix any buildbot failures and tests and arise now that input/output and error are correctly hooked up in all cases. llvm-svn: 200263
2014-01-28 07:43:24 +08:00
m_process (process),
m_read_file (),
m_write_file (write_fd, false),
Add host layer support for pipes. Windows does support pipes, but they do so in a slightly different way. Added a Host layer which abstracts the use of pipes into a new Pipe class that everyone can use. Windows benefits include: - Being able to interrupt running processes when IO is directly hooked up - being able to interrupt long running python scripts - being able to interrupt anything based on ConnectionFileDescriptor llvm-svn: 212220
2014-07-03 05:10:39 +08:00
m_pipe ()
Merging the iohandler branch back into main. The many many benefits include: 1 - Input/Output/Error streams are now handled as real streams not a push style input 2 - auto completion in python embedded interpreter 3 - multi-line input for "script" and "expression" commands now allow you to edit previous/next lines using up and down arrow keys and this makes multi-line input actually a viable thing to use 4 - it is now possible to use curses to drive LLDB (please try the "gui" command) We will need to deal with and fix any buildbot failures and tests and arise now that input/output and error are correctly hooked up in all cases. llvm-svn: 200263
2014-01-28 07:43:24 +08:00
{
Fix race in IOHandlerProcessSTDIO Summary: IOHandlerProcessSTDIO::Run() was opening the pipe for interrupt requests lazily. This was racing with another thread executing IOHandlerProcessSTDIO::Cancel() simultaneously. I fix this by opening the pipe in the object constructor. The pipe will be automatically closed when the object is destroyed. Test Plan: Tests pass on linux. Reviewers: clayborg, ribrdb Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D10060 llvm-svn: 238423
2015-05-28 21:41:08 +08:00
m_pipe.CreateNew(false);
Merging the iohandler branch back into main. The many many benefits include: 1 - Input/Output/Error streams are now handled as real streams not a push style input 2 - auto completion in python embedded interpreter 3 - multi-line input for "script" and "expression" commands now allow you to edit previous/next lines using up and down arrow keys and this makes multi-line input actually a viable thing to use 4 - it is now possible to use curses to drive LLDB (please try the "gui" command) We will need to deal with and fix any buildbot failures and tests and arise now that input/output and error are correctly hooked up in all cases. llvm-svn: 200263
2014-01-28 07:43:24 +08:00
m_read_file.SetDescriptor(GetInputFD(), false);
}
Fix Clang-tidy modernize-use-override warnings in source/Target; other minor fixes. llvm-svn: 251134
2015-10-24 02:39:37 +08:00
~IOHandlerProcessSTDIO() override = default;
Merging the iohandler branch back into main. The many many benefits include: 1 - Input/Output/Error streams are now handled as real streams not a push style input 2 - auto completion in python embedded interpreter 3 - multi-line input for "script" and "expression" commands now allow you to edit previous/next lines using up and down arrow keys and this makes multi-line input actually a viable thing to use 4 - it is now possible to use curses to drive LLDB (please try the "gui" command) We will need to deal with and fix any buildbot failures and tests and arise now that input/output and error are correctly hooked up in all cases. llvm-svn: 200263
2014-01-28 07:43:24 +08:00
// Each IOHandler gets to run until it is done. It should read data
// from the "in" and place output into "out" and "err and return
// when done.
Improve LLDB prompt handling Summary: There is an issue in lldb where the command prompt can appear at the wrong time. The partial fix we have in for this is not working all the time and is introducing unnecessary delays. This change does: - Change Process:SyncIOHandler to use integer start id's for synchronization to avoid it being confused by quick start-stop cycles. I picked this up from a suggested patch by Greg to lldb-dev. - coordinates printing of asynchronous text with the iohandlers. This is also based on a (different) Greg's patch, but I have added stronger synchronization to it to avoid races. Together, these changes solve the prompt problem for me on linux (both with and without libedit). I think they should behave similarly on Mac and FreeBSD and I think they will not make matters worse for windows. Test Plan: Prompt comes out alright. All tests still pass on linux. Reviewers: clayborg, emaste, zturner Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D9823 llvm-svn: 238313
2015-05-27 20:40:32 +08:00
void
Run () override
Merging the iohandler branch back into main. The many many benefits include: 1 - Input/Output/Error streams are now handled as real streams not a push style input 2 - auto completion in python embedded interpreter 3 - multi-line input for "script" and "expression" commands now allow you to edit previous/next lines using up and down arrow keys and this makes multi-line input actually a viable thing to use 4 - it is now possible to use curses to drive LLDB (please try the "gui" command) We will need to deal with and fix any buildbot failures and tests and arise now that input/output and error are correctly hooked up in all cases. llvm-svn: 200263
2014-01-28 07:43:24 +08:00
{
Fix race in IOHandlerProcessSTDIO Summary: IOHandlerProcessSTDIO::Run() was opening the pipe for interrupt requests lazily. This was racing with another thread executing IOHandlerProcessSTDIO::Cancel() simultaneously. I fix this by opening the pipe in the object constructor. The pipe will be automatically closed when the object is destroyed. Test Plan: Tests pass on linux. Reviewers: clayborg, ribrdb Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D10060 llvm-svn: 238423
2015-05-28 21:41:08 +08:00
if (!m_read_file.IsValid() || !m_write_file.IsValid() || !m_pipe.CanRead() || !m_pipe.CanWrite())
Merging the iohandler branch back into main. The many many benefits include: 1 - Input/Output/Error streams are now handled as real streams not a push style input 2 - auto completion in python embedded interpreter 3 - multi-line input for "script" and "expression" commands now allow you to edit previous/next lines using up and down arrow keys and this makes multi-line input actually a viable thing to use 4 - it is now possible to use curses to drive LLDB (please try the "gui" command) We will need to deal with and fix any buildbot failures and tests and arise now that input/output and error are correctly hooked up in all cases. llvm-svn: 200263
2014-01-28 07:43:24 +08:00
{
Fix race in IOHandlerProcessSTDIO Summary: IOHandlerProcessSTDIO::Run() was opening the pipe for interrupt requests lazily. This was racing with another thread executing IOHandlerProcessSTDIO::Cancel() simultaneously. I fix this by opening the pipe in the object constructor. The pipe will be automatically closed when the object is destroyed. Test Plan: Tests pass on linux. Reviewers: clayborg, ribrdb Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D10060 llvm-svn: 238423
2015-05-28 21:41:08 +08:00
SetIsDone(true);
return;
}
SetIsDone(false);
const int read_fd = m_read_file.GetDescriptor();
TerminalState terminal_state;
terminal_state.Save (read_fd, false);
Terminal terminal(read_fd);
terminal.SetCanonical(false);
terminal.SetEcho(false);
Fixing the Windows build for the changes brought in from the iohandler merge. llvm-svn: 200565
2014-02-01 02:48:46 +08:00
// FD_ZERO, FD_SET are not supported on windows
Replace some _MSC_VER with _WIN32. This allows to use some code for mingw which was previously only used for MSVC. llvm-svn: 203651
2014-03-12 18:45:23 +08:00
#ifndef _WIN32
Fix race in IOHandlerProcessSTDIO Summary: IOHandlerProcessSTDIO::Run() was opening the pipe for interrupt requests lazily. This was racing with another thread executing IOHandlerProcessSTDIO::Cancel() simultaneously. I fix this by opening the pipe in the object constructor. The pipe will be automatically closed when the object is destroyed. Test Plan: Tests pass on linux. Reviewers: clayborg, ribrdb Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D10060 llvm-svn: 238423
2015-05-28 21:41:08 +08:00
const int pipe_read_fd = m_pipe.GetReadFileDescriptor();
while (!GetIsDone())
{
fd_set read_fdset;
FD_ZERO (&read_fdset);
FD_SET (read_fd, &read_fdset);
FD_SET (pipe_read_fd, &read_fdset);
const int nfds = std::max<int>(read_fd, pipe_read_fd) + 1;
int num_set_fds = select (nfds, &read_fdset, NULL, NULL, NULL);
if (num_set_fds < 0)
{
const int select_errno = errno;
if (select_errno != EINTR)
SetIsDone(true);
}
else if (num_set_fds > 0)
{
char ch = 0;
size_t n;
if (FD_ISSET (read_fd, &read_fdset))
Merging the iohandler branch back into main. The many many benefits include: 1 - Input/Output/Error streams are now handled as real streams not a push style input 2 - auto completion in python embedded interpreter 3 - multi-line input for "script" and "expression" commands now allow you to edit previous/next lines using up and down arrow keys and this makes multi-line input actually a viable thing to use 4 - it is now possible to use curses to drive LLDB (please try the "gui" command) We will need to deal with and fix any buildbot failures and tests and arise now that input/output and error are correctly hooked up in all cases. llvm-svn: 200263
2014-01-28 07:43:24 +08:00
{
Fix race in IOHandlerProcessSTDIO Summary: IOHandlerProcessSTDIO::Run() was opening the pipe for interrupt requests lazily. This was racing with another thread executing IOHandlerProcessSTDIO::Cancel() simultaneously. I fix this by opening the pipe in the object constructor. The pipe will be automatically closed when the object is destroyed. Test Plan: Tests pass on linux. Reviewers: clayborg, ribrdb Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D10060 llvm-svn: 238423
2015-05-28 21:41:08 +08:00
n = 1;
if (m_read_file.Read(&ch, n).Success() && n == 1)
Merging the iohandler branch back into main. The many many benefits include: 1 - Input/Output/Error streams are now handled as real streams not a push style input 2 - auto completion in python embedded interpreter 3 - multi-line input for "script" and "expression" commands now allow you to edit previous/next lines using up and down arrow keys and this makes multi-line input actually a viable thing to use 4 - it is now possible to use curses to drive LLDB (please try the "gui" command) We will need to deal with and fix any buildbot failures and tests and arise now that input/output and error are correctly hooked up in all cases. llvm-svn: 200263
2014-01-28 07:43:24 +08:00
{
Fix race in IOHandlerProcessSTDIO Summary: IOHandlerProcessSTDIO::Run() was opening the pipe for interrupt requests lazily. This was racing with another thread executing IOHandlerProcessSTDIO::Cancel() simultaneously. I fix this by opening the pipe in the object constructor. The pipe will be automatically closed when the object is destroyed. Test Plan: Tests pass on linux. Reviewers: clayborg, ribrdb Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D10060 llvm-svn: 238423
2015-05-28 21:41:08 +08:00
if (m_write_file.Write(&ch, n).Fail() || n != 1)
Merging the iohandler branch back into main. The many many benefits include: 1 - Input/Output/Error streams are now handled as real streams not a push style input 2 - auto completion in python embedded interpreter 3 - multi-line input for "script" and "expression" commands now allow you to edit previous/next lines using up and down arrow keys and this makes multi-line input actually a viable thing to use 4 - it is now possible to use curses to drive LLDB (please try the "gui" command) We will need to deal with and fix any buildbot failures and tests and arise now that input/output and error are correctly hooked up in all cases. llvm-svn: 200263
2014-01-28 07:43:24 +08:00
SetIsDone(true);
}
Fix race in IOHandlerProcessSTDIO Summary: IOHandlerProcessSTDIO::Run() was opening the pipe for interrupt requests lazily. This was racing with another thread executing IOHandlerProcessSTDIO::Cancel() simultaneously. I fix this by opening the pipe in the object constructor. The pipe will be automatically closed when the object is destroyed. Test Plan: Tests pass on linux. Reviewers: clayborg, ribrdb Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D10060 llvm-svn: 238423
2015-05-28 21:41:08 +08:00
else
SetIsDone(true);
}
if (FD_ISSET (pipe_read_fd, &read_fdset))
{
size_t bytes_read;
// Consume the interrupt byte
Error error = m_pipe.Read(&ch, 1, bytes_read);
if (error.Success())
Merging the iohandler branch back into main. The many many benefits include: 1 - Input/Output/Error streams are now handled as real streams not a push style input 2 - auto completion in python embedded interpreter 3 - multi-line input for "script" and "expression" commands now allow you to edit previous/next lines using up and down arrow keys and this makes multi-line input actually a viable thing to use 4 - it is now possible to use curses to drive LLDB (please try the "gui" command) We will need to deal with and fix any buildbot failures and tests and arise now that input/output and error are correctly hooked up in all cases. llvm-svn: 200263
2014-01-28 07:43:24 +08:00
{
Fix race in IOHandlerProcessSTDIO Summary: IOHandlerProcessSTDIO::Run() was opening the pipe for interrupt requests lazily. This was racing with another thread executing IOHandlerProcessSTDIO::Cancel() simultaneously. I fix this by opening the pipe in the object constructor. The pipe will be automatically closed when the object is destroyed. Test Plan: Tests pass on linux. Reviewers: clayborg, ribrdb Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D10060 llvm-svn: 238423
2015-05-28 21:41:08 +08:00
switch (ch)
Merging the iohandler branch back into main. The many many benefits include: 1 - Input/Output/Error streams are now handled as real streams not a push style input 2 - auto completion in python embedded interpreter 3 - multi-line input for "script" and "expression" commands now allow you to edit previous/next lines using up and down arrow keys and this makes multi-line input actually a viable thing to use 4 - it is now possible to use curses to drive LLDB (please try the "gui" command) We will need to deal with and fix any buildbot failures and tests and arise now that input/output and error are correctly hooked up in all cases. llvm-svn: 200263
2014-01-28 07:43:24 +08:00
{
Fix race in IOHandlerProcessSTDIO Summary: IOHandlerProcessSTDIO::Run() was opening the pipe for interrupt requests lazily. This was racing with another thread executing IOHandlerProcessSTDIO::Cancel() simultaneously. I fix this by opening the pipe in the object constructor. The pipe will be automatically closed when the object is destroyed. Test Plan: Tests pass on linux. Reviewers: clayborg, ribrdb Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D10060 llvm-svn: 238423
2015-05-28 21:41:08 +08:00
case 'q':
Merging the iohandler branch back into main. The many many benefits include: 1 - Input/Output/Error streams are now handled as real streams not a push style input 2 - auto completion in python embedded interpreter 3 - multi-line input for "script" and "expression" commands now allow you to edit previous/next lines using up and down arrow keys and this makes multi-line input actually a viable thing to use 4 - it is now possible to use curses to drive LLDB (please try the "gui" command) We will need to deal with and fix any buildbot failures and tests and arise now that input/output and error are correctly hooked up in all cases. llvm-svn: 200263
2014-01-28 07:43:24 +08:00
SetIsDone(true);
Fix race in IOHandlerProcessSTDIO Summary: IOHandlerProcessSTDIO::Run() was opening the pipe for interrupt requests lazily. This was racing with another thread executing IOHandlerProcessSTDIO::Cancel() simultaneously. I fix this by opening the pipe in the object constructor. The pipe will be automatically closed when the object is destroyed. Test Plan: Tests pass on linux. Reviewers: clayborg, ribrdb Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D10060 llvm-svn: 238423
2015-05-28 21:41:08 +08:00
break;
case 'i':
if (StateIsRunningState(m_process->GetState()))
Resumbit "Fix race condition during process detach" This is a resubmission of r248371. It also incorporates the process event hijack patch by Kyrill Lapshin in D12968. llvm-svn: 249554
2015-10-07 23:11:11 +08:00
m_process->SendAsyncInterrupt();
Fix race in IOHandlerProcessSTDIO Summary: IOHandlerProcessSTDIO::Run() was opening the pipe for interrupt requests lazily. This was racing with another thread executing IOHandlerProcessSTDIO::Cancel() simultaneously. I fix this by opening the pipe in the object constructor. The pipe will be automatically closed when the object is destroyed. Test Plan: Tests pass on linux. Reviewers: clayborg, ribrdb Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D10060 llvm-svn: 238423
2015-05-28 21:41:08 +08:00
break;
Merging the iohandler branch back into main. The many many benefits include: 1 - Input/Output/Error streams are now handled as real streams not a push style input 2 - auto completion in python embedded interpreter 3 - multi-line input for "script" and "expression" commands now allow you to edit previous/next lines using up and down arrow keys and this makes multi-line input actually a viable thing to use 4 - it is now possible to use curses to drive LLDB (please try the "gui" command) We will need to deal with and fix any buildbot failures and tests and arise now that input/output and error are correctly hooked up in all cases. llvm-svn: 200263
2014-01-28 07:43:24 +08:00
}
}
}
}
}
Fix race in IOHandlerProcessSTDIO Summary: IOHandlerProcessSTDIO::Run() was opening the pipe for interrupt requests lazily. This was racing with another thread executing IOHandlerProcessSTDIO::Cancel() simultaneously. I fix this by opening the pipe in the object constructor. The pipe will be automatically closed when the object is destroyed. Test Plan: Tests pass on linux. Reviewers: clayborg, ribrdb Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D10060 llvm-svn: 238423
2015-05-28 21:41:08 +08:00
#endif
terminal_state.Restore();
Merging the iohandler branch back into main. The many many benefits include: 1 - Input/Output/Error streams are now handled as real streams not a push style input 2 - auto completion in python embedded interpreter 3 - multi-line input for "script" and "expression" commands now allow you to edit previous/next lines using up and down arrow keys and this makes multi-line input actually a viable thing to use 4 - it is now possible to use curses to drive LLDB (please try the "gui" command) We will need to deal with and fix any buildbot failures and tests and arise now that input/output and error are correctly hooked up in all cases. llvm-svn: 200263
2014-01-28 07:43:24 +08:00
}
Improve LLDB prompt handling Summary: There is an issue in lldb where the command prompt can appear at the wrong time. The partial fix we have in for this is not working all the time and is introducing unnecessary delays. This change does: - Change Process:SyncIOHandler to use integer start id's for synchronization to avoid it being confused by quick start-stop cycles. I picked this up from a suggested patch by Greg to lldb-dev. - coordinates printing of asynchronous text with the iohandlers. This is also based on a (different) Greg's patch, but I have added stronger synchronization to it to avoid races. Together, these changes solve the prompt problem for me on linux (both with and without libedit). I think they should behave similarly on Mac and FreeBSD and I think they will not make matters worse for windows. Test Plan: Prompt comes out alright. All tests still pass on linux. Reviewers: clayborg, emaste, zturner Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D9823 llvm-svn: 238313
2015-05-27 20:40:32 +08:00
void
Cancel () override
Merging the iohandler branch back into main. The many many benefits include: 1 - Input/Output/Error streams are now handled as real streams not a push style input 2 - auto completion in python embedded interpreter 3 - multi-line input for "script" and "expression" commands now allow you to edit previous/next lines using up and down arrow keys and this makes multi-line input actually a viable thing to use 4 - it is now possible to use curses to drive LLDB (please try the "gui" command) We will need to deal with and fix any buildbot failures and tests and arise now that input/output and error are correctly hooked up in all cases. llvm-svn: 200263
2014-01-28 07:43:24 +08:00
{
A better long term fix for stopping the process when it is running by writing to the pipe that was used for cancel. We now write a 'q' to indicate to exit the IOHandlerProcessSTDIO::Run(), and a 'i' to interrupt the process. This should make this code safer to use in a signal handler function. llvm-svn: 202311
2014-02-27 06:47:33 +08:00
char ch = 'q'; // Send 'q' for quit
Enhance the Pipe interface for better portability. This patch makes a number of improvements to the Pipe interface. 1) An interface (PipeBase) is provided which exposes pure virtual methods for any implementation of Pipe to override. While not strictly necessary, this helps catch errors where the interfaces are out of sync. 2) All methods return lldb_private::Error instead of returning bool or void. This allows richer error information to be propagated up to LLDB. 3) A new ReadWithTimeout() method is exposed in the base class and implemented on Windows. 4) Support for both named and anonymous pipes is exposed through the base interface and implemented on Windows. For creating a new pipe, both named and anonymous pipes are supported, and for opening an existing pipe, only named pipes are supported. New methods described in points #3 and #4 are stubbed out on posix, but fully implemented on Windows. These should be implemented by someone on the linux / mac / bsd side. Reviewed by: Greg Clayton, Oleksiy Vyalov Differential Revision: http://reviews.llvm.org/D6686 llvm-svn: 224442
2014-12-18 02:02:19 +08:00
size_t bytes_written = 0;
m_pipe.Write(&ch, 1, bytes_written);
Merging the iohandler branch back into main. The many many benefits include: 1 - Input/Output/Error streams are now handled as real streams not a push style input 2 - auto completion in python embedded interpreter 3 - multi-line input for "script" and "expression" commands now allow you to edit previous/next lines using up and down arrow keys and this makes multi-line input actually a viable thing to use 4 - it is now possible to use curses to drive LLDB (please try the "gui" command) We will need to deal with and fix any buildbot failures and tests and arise now that input/output and error are correctly hooked up in all cases. llvm-svn: 200263
2014-01-28 07:43:24 +08:00
}
Fixed the command line LLDB so that "CTRL+C" will interrupt a running process again. llvm-svn: 202086
2014-02-25 06:50:57 +08:00
Improve LLDB prompt handling Summary: There is an issue in lldb where the command prompt can appear at the wrong time. The partial fix we have in for this is not working all the time and is introducing unnecessary delays. This change does: - Change Process:SyncIOHandler to use integer start id's for synchronization to avoid it being confused by quick start-stop cycles. I picked this up from a suggested patch by Greg to lldb-dev. - coordinates printing of asynchronous text with the iohandlers. This is also based on a (different) Greg's patch, but I have added stronger synchronization to it to avoid races. Together, these changes solve the prompt problem for me on linux (both with and without libedit). I think they should behave similarly on Mac and FreeBSD and I think they will not make matters worse for windows. Test Plan: Prompt comes out alright. All tests still pass on linux. Reviewers: clayborg, emaste, zturner Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D9823 llvm-svn: 238313
2015-05-27 20:40:32 +08:00
bool
Interrupt () override
Fixed the command line LLDB so that "CTRL+C" will interrupt a running process again. llvm-svn: 202086
2014-02-25 06:50:57 +08:00
{
A better long term fix for stopping the process when it is running by writing to the pipe that was used for cancel. We now write a 'q' to indicate to exit the IOHandlerProcessSTDIO::Run(), and a 'i' to interrupt the process. This should make this code safer to use in a signal handler function. llvm-svn: 202311
2014-02-27 06:47:33 +08:00
// Do only things that are safe to do in an interrupt context (like in
// a SIGINT handler), like write 1 byte to a file descriptor. This will
// interrupt the IOHandlerProcessSTDIO::Run() and we can look at the byte
Resumbit "Fix race condition during process detach" This is a resubmission of r248371. It also incorporates the process event hijack patch by Kyrill Lapshin in D12968. llvm-svn: 249554
2015-10-07 23:11:11 +08:00
// that was written to the pipe and then call m_process->SendAsyncInterrupt()
// from a much safer location in code.
^C wasn't interrupting an expression during a long evaluation or deadlock. The problem was that we have an IOHandler thread that services the IOHandler stack. The command interepter is on the top of the stack and it receives a "expression ..." command, and it calls the IOHandlerIsComplete() callback in the command interpereter delegate which runs an expression. This causes the IOHandlerProcessSTDIO to be pushed, but since we are running the code from the IOHandler thread, it won't get run. When CTRL+C is pressed, we do deliver the interrupt to the IOHandlerProcessSTDIO::Interrupt() function, but it was always writing 'i' to the interrupt pipe, even if we weren't actively reading from the debugger input and the pipes. This fix works around the issue by directly issuing the async interrupt to the process if the process is running. A longer term more correct fix would to be run the IOHandler thread and have it just do the determination of the input and when complete input is received, run the code that handles that input on another thread and syncronize with that other thread to detect when more input is desired. That change is too big to make right now, so this fix will tide us over until we can get there. <rdar://problem/16556228> llvm-svn: 213196
2014-07-17 05:05:41 +08:00
if (m_active)
{
char ch = 'i'; // Send 'i' for interrupt
Enhance the Pipe interface for better portability. This patch makes a number of improvements to the Pipe interface. 1) An interface (PipeBase) is provided which exposes pure virtual methods for any implementation of Pipe to override. While not strictly necessary, this helps catch errors where the interfaces are out of sync. 2) All methods return lldb_private::Error instead of returning bool or void. This allows richer error information to be propagated up to LLDB. 3) A new ReadWithTimeout() method is exposed in the base class and implemented on Windows. 4) Support for both named and anonymous pipes is exposed through the base interface and implemented on Windows. For creating a new pipe, both named and anonymous pipes are supported, and for opening an existing pipe, only named pipes are supported. New methods described in points #3 and #4 are stubbed out on posix, but fully implemented on Windows. These should be implemented by someone on the linux / mac / bsd side. Reviewed by: Greg Clayton, Oleksiy Vyalov Differential Revision: http://reviews.llvm.org/D6686 llvm-svn: 224442
2014-12-18 02:02:19 +08:00
size_t bytes_written = 0;
Error result = m_pipe.Write(&ch, 1, bytes_written);
return result.Success();
^C wasn't interrupting an expression during a long evaluation or deadlock. The problem was that we have an IOHandler thread that services the IOHandler stack. The command interepter is on the top of the stack and it receives a "expression ..." command, and it calls the IOHandlerIsComplete() callback in the command interpereter delegate which runs an expression. This causes the IOHandlerProcessSTDIO to be pushed, but since we are running the code from the IOHandler thread, it won't get run. When CTRL+C is pressed, we do deliver the interrupt to the IOHandlerProcessSTDIO::Interrupt() function, but it was always writing 'i' to the interrupt pipe, even if we weren't actively reading from the debugger input and the pipes. This fix works around the issue by directly issuing the async interrupt to the process if the process is running. A longer term more correct fix would to be run the IOHandler thread and have it just do the determination of the input and when complete input is received, run the code that handles that input on another thread and syncronize with that other thread to detect when more input is desired. That change is too big to make right now, so this fix will tide us over until we can get there. <rdar://problem/16556228> llvm-svn: 213196
2014-07-17 05:05:41 +08:00
}
else
{
// This IOHandler might be pushed on the stack, but not being run currently
// so do the right thing if we aren't actively watching for STDIN by sending
// the interrupt to the process. Otherwise the write to the pipe above would
// do nothing. This can happen when the command interpreter is running and
// gets a "expression ...". It will be on the IOHandler thread and sending
// the input is complete to the delegate which will cause the expression to
// run, which will push the process IO handler, but not run it.
if (StateIsRunningState(m_process->GetState()))
{
m_process->SendAsyncInterrupt();
return true;
}
}
return false;
Fixed the command line LLDB so that "CTRL+C" will interrupt a running process again. llvm-svn: 202086
2014-02-25 06:50:57 +08:00
}
Merging the iohandler branch back into main. The many many benefits include: 1 - Input/Output/Error streams are now handled as real streams not a push style input 2 - auto completion in python embedded interpreter 3 - multi-line input for "script" and "expression" commands now allow you to edit previous/next lines using up and down arrow keys and this makes multi-line input actually a viable thing to use 4 - it is now possible to use curses to drive LLDB (please try the "gui" command) We will need to deal with and fix any buildbot failures and tests and arise now that input/output and error are correctly hooked up in all cases. llvm-svn: 200263
2014-01-28 07:43:24 +08:00
Improve LLDB prompt handling Summary: There is an issue in lldb where the command prompt can appear at the wrong time. The partial fix we have in for this is not working all the time and is introducing unnecessary delays. This change does: - Change Process:SyncIOHandler to use integer start id's for synchronization to avoid it being confused by quick start-stop cycles. I picked this up from a suggested patch by Greg to lldb-dev. - coordinates printing of asynchronous text with the iohandlers. This is also based on a (different) Greg's patch, but I have added stronger synchronization to it to avoid races. Together, these changes solve the prompt problem for me on linux (both with and without libedit). I think they should behave similarly on Mac and FreeBSD and I think they will not make matters worse for windows. Test Plan: Prompt comes out alright. All tests still pass on linux. Reviewers: clayborg, emaste, zturner Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D9823 llvm-svn: 238313
2015-05-27 20:40:32 +08:00
void
GotEOF() override
Merging the iohandler branch back into main. The many many benefits include: 1 - Input/Output/Error streams are now handled as real streams not a push style input 2 - auto completion in python embedded interpreter 3 - multi-line input for "script" and "expression" commands now allow you to edit previous/next lines using up and down arrow keys and this makes multi-line input actually a viable thing to use 4 - it is now possible to use curses to drive LLDB (please try the "gui" command) We will need to deal with and fix any buildbot failures and tests and arise now that input/output and error are correctly hooked up in all cases. llvm-svn: 200263
2014-01-28 07:43:24 +08:00
{
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
}
Merging the iohandler branch back into main. The many many benefits include: 1 - Input/Output/Error streams are now handled as real streams not a push style input 2 - auto completion in python embedded interpreter 3 - multi-line input for "script" and "expression" commands now allow you to edit previous/next lines using up and down arrow keys and this makes multi-line input actually a viable thing to use 4 - it is now possible to use curses to drive LLDB (please try the "gui" command) We will need to deal with and fix any buildbot failures and tests and arise now that input/output and error are correctly hooked up in all cases. llvm-svn: 200263
2014-01-28 07:43:24 +08:00
protected:
Process *m_process;
File m_read_file; // Read from this file (usually actual STDIN for LLDB
File m_write_file; // Write to this file (usually the master pty for getting io to debuggee)
Add host layer support for pipes. Windows does support pipes, but they do so in a slightly different way. Added a Host layer which abstracts the use of pipes into a new Pipe class that everyone can use. Windows benefits include: - Being able to interrupt running processes when IO is directly hooked up - being able to interrupt long running python scripts - being able to interrupt anything based on ConnectionFileDescriptor llvm-svn: 212220
2014-07-03 05:10:39 +08:00
Pipe m_pipe;
Merging the iohandler branch back into main. The many many benefits include: 1 - Input/Output/Error streams are now handled as real streams not a push style input 2 - auto completion in python embedded interpreter 3 - multi-line input for "script" and "expression" commands now allow you to edit previous/next lines using up and down arrow keys and this makes multi-line input actually a viable thing to use 4 - it is now possible to use curses to drive LLDB (please try the "gui" command) We will need to deal with and fix any buildbot failures and tests and arise now that input/output and error are correctly hooked up in all cases. llvm-svn: 200263
2014-01-28 07:43:24 +08:00
};
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
Merging the iohandler branch back into main. The many many benefits include: 1 - Input/Output/Error streams are now handled as real streams not a push style input 2 - auto completion in python embedded interpreter 3 - multi-line input for "script" and "expression" commands now allow you to edit previous/next lines using up and down arrow keys and this makes multi-line input actually a viable thing to use 4 - it is now possible to use curses to drive LLDB (please try the "gui" command) We will need to deal with and fix any buildbot failures and tests and arise now that input/output and error are correctly hooked up in all cases. llvm-svn: 200263
2014-01-28 07:43:24 +08:00
Process::SetSTDIOFileDescriptor (int fd)
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
Merging the iohandler branch back into main. The many many benefits include: 1 - Input/Output/Error streams are now handled as real streams not a push style input 2 - auto completion in python embedded interpreter 3 - multi-line input for "script" and "expression" commands now allow you to edit previous/next lines using up and down arrow keys and this makes multi-line input actually a viable thing to use 4 - it is now possible to use curses to drive LLDB (please try the "gui" command) We will need to deal with and fix any buildbot failures and tests and arise now that input/output and error are correctly hooked up in all cases. llvm-svn: 200263
2014-01-28 07:43:24 +08:00
std::unique_ptr<ConnectionFileDescriptor> conn_ap (new ConnectionFileDescriptor (fd, true));
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
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())
Merging the iohandler branch back into main. The many many benefits include: 1 - Input/Output/Error streams are now handled as real streams not a push style input 2 - auto completion in python embedded interpreter 3 - multi-line input for "script" and "expression" commands now allow you to edit previous/next lines using up and down arrow keys and this makes multi-line input actually a viable thing to use 4 - it is now possible to use curses to drive LLDB (please try the "gui" command) We will need to deal with and fix any buildbot failures and tests and arise now that input/output and error are correctly hooked up in all cases. llvm-svn: 200263
2014-01-28 07:43:24 +08:00
m_process_input_reader.reset (new IOHandlerProcessSTDIO (this, fd));
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
}
}
}
"size_t" isn't always 64 bit, it is 32 bit on 32 bit systems. All printf style statements that were assuming size_t were 64 bit were changed, and they were also changed to display them as unsigned values as "size_t" isn't signed. If you print anything with 'size_t', please cast it to "uint64_t" in the printf and use PRIu64 or PRIx64. llvm-svn: 202738
2014-03-04 03:15:20 +08:00
bool
Process::ProcessIOHandlerIsActive ()
{
IOHandlerSP io_handler_sp (m_process_input_reader);
if (io_handler_sp)
Have the Process hold a weak_ptr to the Target. llvm-svn: 246578
2015-09-02 04:02:29 +08:00
return GetTarget().GetDebugger().IsTopIOHandler (io_handler_sp);
"size_t" isn't always 64 bit, it is 32 bit on 32 bit systems. All printf style statements that were assuming size_t were 64 bit were changed, and they were also changed to display them as unsigned values as "size_t" isn't signed. If you print anything with 'size_t', please cast it to "uint64_t" in the printf and use PRIu64 or PRIx64. llvm-svn: 202738
2014-03-04 03:15:20 +08:00
return false;
}
Fixed all overlapping prompt issues. I carefully reviewed exactly how the IOHandlers interact and found places where we weren't properly controlling things. There should be no overlapping prompts and all output should now come out in a controlled fashion. <rdar://problem/16111293> llvm-svn: 202525
2014-03-01 02:22:24 +08:00
bool
Merging the iohandler branch back into main. The many many benefits include: 1 - Input/Output/Error streams are now handled as real streams not a push style input 2 - auto completion in python embedded interpreter 3 - multi-line input for "script" and "expression" commands now allow you to edit previous/next lines using up and down arrow keys and this makes multi-line input actually a viable thing to use 4 - it is now possible to use curses to drive LLDB (please try the "gui" command) We will need to deal with and fix any buildbot failures and tests and arise now that input/output and error are correctly hooked up in all cases. llvm-svn: 200263
2014-01-28 07:43:24 +08:00
Process::PushProcessIOHandler ()
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
{
Merging the iohandler branch back into main. The many many benefits include: 1 - Input/Output/Error streams are now handled as real streams not a push style input 2 - auto completion in python embedded interpreter 3 - multi-line input for "script" and "expression" commands now allow you to edit previous/next lines using up and down arrow keys and this makes multi-line input actually a viable thing to use 4 - it is now possible to use curses to drive LLDB (please try the "gui" command) We will need to deal with and fix any buildbot failures and tests and arise now that input/output and error are correctly hooked up in all cases. llvm-svn: 200263
2014-01-28 07:43:24 +08:00
IOHandlerSP io_handler_sp (m_process_input_reader);
if (io_handler_sp)
{
Improve LLDB prompt handling Summary: There is an issue in lldb where the command prompt can appear at the wrong time. The partial fix we have in for this is not working all the time and is introducing unnecessary delays. This change does: - Change Process:SyncIOHandler to use integer start id's for synchronization to avoid it being confused by quick start-stop cycles. I picked this up from a suggested patch by Greg to lldb-dev. - coordinates printing of asynchronous text with the iohandlers. This is also based on a (different) Greg's patch, but I have added stronger synchronization to it to avoid races. Together, these changes solve the prompt problem for me on linux (both with and without libedit). I think they should behave similarly on Mac and FreeBSD and I think they will not make matters worse for windows. Test Plan: Prompt comes out alright. All tests still pass on linux. Reviewers: clayborg, emaste, zturner Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D9823 llvm-svn: 238313
2015-05-27 20:40:32 +08:00
Log *log(lldb_private::GetLogIfAllCategoriesSet (LIBLLDB_LOG_PROCESS));
if (log)
log->Printf("Process::%s pushing IO handler", __FUNCTION__);
Merging the iohandler branch back into main. The many many benefits include: 1 - Input/Output/Error streams are now handled as real streams not a push style input 2 - auto completion in python embedded interpreter 3 - multi-line input for "script" and "expression" commands now allow you to edit previous/next lines using up and down arrow keys and this makes multi-line input actually a viable thing to use 4 - it is now possible to use curses to drive LLDB (please try the "gui" command) We will need to deal with and fix any buildbot failures and tests and arise now that input/output and error are correctly hooked up in all cases. llvm-svn: 200263
2014-01-28 07:43:24 +08:00
io_handler_sp->SetIsDone(false);
Have the Process hold a weak_ptr to the Target. llvm-svn: 246578
2015-09-02 04:02:29 +08:00
GetTarget().GetDebugger().PushIOHandler (io_handler_sp);
Fixed all overlapping prompt issues. I carefully reviewed exactly how the IOHandlers interact and found places where we weren't properly controlling things. There should be no overlapping prompts and all output should now come out in a controlled fashion. <rdar://problem/16111293> llvm-svn: 202525
2014-03-01 02:22:24 +08:00
return true;
Merging the iohandler branch back into main. The many many benefits include: 1 - Input/Output/Error streams are now handled as real streams not a push style input 2 - auto completion in python embedded interpreter 3 - multi-line input for "script" and "expression" commands now allow you to edit previous/next lines using up and down arrow keys and this makes multi-line input actually a viable thing to use 4 - it is now possible to use curses to drive LLDB (please try the "gui" command) We will need to deal with and fix any buildbot failures and tests and arise now that input/output and error are correctly hooked up in all cases. llvm-svn: 200263
2014-01-28 07:43:24 +08:00
}
Fixed all overlapping prompt issues. I carefully reviewed exactly how the IOHandlers interact and found places where we weren't properly controlling things. There should be no overlapping prompts and all output should now come out in a controlled fashion. <rdar://problem/16111293> llvm-svn: 202525
2014-03-01 02:22:24 +08:00
return false;
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
}
Fixed all overlapping prompt issues. I carefully reviewed exactly how the IOHandlers interact and found places where we weren't properly controlling things. There should be no overlapping prompts and all output should now come out in a controlled fashion. <rdar://problem/16111293> llvm-svn: 202525
2014-03-01 02:22:24 +08:00
bool
Merging the iohandler branch back into main. The many many benefits include: 1 - Input/Output/Error streams are now handled as real streams not a push style input 2 - auto completion in python embedded interpreter 3 - multi-line input for "script" and "expression" commands now allow you to edit previous/next lines using up and down arrow keys and this makes multi-line input actually a viable thing to use 4 - it is now possible to use curses to drive LLDB (please try the "gui" command) We will need to deal with and fix any buildbot failures and tests and arise now that input/output and error are correctly hooked up in all cases. llvm-svn: 200263
2014-01-28 07:43:24 +08:00
Process::PopProcessIOHandler ()
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
{
Merging the iohandler branch back into main. The many many benefits include: 1 - Input/Output/Error streams are now handled as real streams not a push style input 2 - auto completion in python embedded interpreter 3 - multi-line input for "script" and "expression" commands now allow you to edit previous/next lines using up and down arrow keys and this makes multi-line input actually a viable thing to use 4 - it is now possible to use curses to drive LLDB (please try the "gui" command) We will need to deal with and fix any buildbot failures and tests and arise now that input/output and error are correctly hooked up in all cases. llvm-svn: 200263
2014-01-28 07:43:24 +08:00
IOHandlerSP io_handler_sp (m_process_input_reader);
if (io_handler_sp)
Have the Process hold a weak_ptr to the Target. llvm-svn: 246578
2015-09-02 04:02:29 +08:00
return GetTarget().GetDebugger().PopIOHandler (io_handler_sp);
Fixed all overlapping prompt issues. I carefully reviewed exactly how the IOHandlers interact and found places where we weren't properly controlling things. There should be no overlapping prompts and all output should now come out in a controlled fashion. <rdar://problem/16111293> llvm-svn: 202525
2014-03-01 02:22:24 +08:00
return false;
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
}
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
{
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
}
Fix a misunderstanding of the ThreadPlan::OkayToDiscard flag in InferiorCallPOSIX. It was set to true, but all plans run by RunThreadPlan need to have this set to false so they will return control to RunThreadPlan without consulting plans higher on the stack. Since this seems like a common error, I also modified RunThreadPlan to enforce this behavior. <rdar://problem/22543166> llvm-svn: 250084
2015-10-13 03:11:03 +08:00
namespace
{
// RestorePlanState is used to record the "is private", "is master" and "okay to discard" fields of
// the plan we are running, and reset it on Clean or on destruction.
// It will only reset the state once, so you can call Clean and then monkey with the state and it
// won't get reset on you again.
class RestorePlanState
{
public:
RestorePlanState (lldb::ThreadPlanSP thread_plan_sp) :
m_thread_plan_sp(thread_plan_sp),
m_already_reset(false)
{
if (m_thread_plan_sp)
{
m_private = m_thread_plan_sp->GetPrivate();
m_is_master = m_thread_plan_sp->IsMasterPlan();
m_okay_to_discard = m_thread_plan_sp->OkayToDiscard();
}
}
~RestorePlanState()
{
Clean();
}
void
Clean ()
{
if (!m_already_reset && m_thread_plan_sp)
{
m_already_reset = true;
m_thread_plan_sp->SetPrivate(m_private);
m_thread_plan_sp->SetIsMasterPlan (m_is_master);
m_thread_plan_sp->SetOkayToDiscard(m_okay_to_discard);
}
}
Fix Clang-tidy modernize-use-override warnings in source/Target; other minor fixes. llvm-svn: 251134
2015-10-24 02:39:37 +08:00
Fix a misunderstanding of the ThreadPlan::OkayToDiscard flag in InferiorCallPOSIX. It was set to true, but all plans run by RunThreadPlan need to have this set to false so they will return control to RunThreadPlan without consulting plans higher on the stack. Since this seems like a common error, I also modified RunThreadPlan to enforce this behavior. <rdar://problem/22543166> llvm-svn: 250084
2015-10-13 03:11:03 +08:00
private:
lldb::ThreadPlanSP m_thread_plan_sp;
bool m_already_reset;
bool m_private;
bool m_is_master;
bool m_okay_to_discard;
};
Fix Clang-tidy modernize-use-override warnings in source/Target; other minor fixes. llvm-svn: 251134
2015-10-24 02:39:37 +08:00
} // anonymous namespace
Fix a misunderstanding of the ThreadPlan::OkayToDiscard flag in InferiorCallPOSIX. It was set to true, but all plans run by RunThreadPlan need to have this set to false so they will return control to RunThreadPlan without consulting plans higher on the stack. Since this seems like a common error, I also modified RunThreadPlan to enforce this behavior. <rdar://problem/22543166> llvm-svn: 250084
2015-10-13 03:11:03 +08:00
Make the Expression Execution result enum available to the SB API layer. Add a callback that will allow an expression to be cancelled between the expression evaluation stages (for the ClangUserExpressions.) <rdar://problem/16790467>, <rdar://problem/16573440> llvm-svn: 207944
2014-05-05 10:26:40 +08:00
ExpressionResults
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,
This patch does a couple of things. It completes the job of using EvaluateExpressionOptions consistently throughout the inferior function calling mechanism in lldb begun in Greg's patch r194009. It removes a handful of alternate calls into the ClangUserExpression/ClangFunction/ThreadPlanCallFunction which were there for convenience. Using the EvaluateExpressionOptions removes the need for them. Using that it gets the --debug option from Greg's patch to work cleanly. It also adds another EvaluateExpressionOption to not trap exceptions when running expressions. You shouldn't use this option unless you KNOW your expression can't throw beyond itself. This is: <rdar://problem/15374885> At present this is only available through the SB API's or python. It fixes a bug where function calls would unset the ObjC & C++ exception breakpoints without checking whether they were set by somebody else already. llvm-svn: 194182
2013-11-07 08:11:47 +08:00
const EvaluateExpressionOptions &options,
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)
{
Rename eExecution*** to eExpression*** to be consistent with the result type. llvm-svn: 207945
2014-05-05 10:47:44 +08:00
ExpressionResults return_value = eExpressionSetupError;
sweep up -Wformat warnings from gcc This is a purely mechanical change explicitly casting any parameters for printf style conversion. This cleans up the warnings emitted by gcc 4.8 on Linux. llvm-svn: 205607
2014-04-04 12:06:10 +08:00
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.");
Rename eExecution*** to eExpression*** to be consistent with the result type. llvm-svn: 207945
2014-05-05 10:47:44 +08:00
return eExpressionSetupError;
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
}
sweep up -Wformat warnings from gcc This is a purely mechanical change explicitly casting any parameters for printf style conversion. This cleans up the warnings emitted by gcc 4.8 on Linux. llvm-svn: 205607
2014-04-04 12:06:10 +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.");
Rename eExecution*** to eExpression*** to be consistent with the result type. llvm-svn: 207945
2014-05-05 10:47:44 +08:00
return eExpressionSetupError;
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
}
sweep up -Wformat warnings from gcc This is a purely mechanical change explicitly casting any parameters for printf style conversion. This cleans up the warnings emitted by gcc 4.8 on Linux. llvm-svn: 205607
2014-04-04 12:06:10 +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
if (exe_ctx.GetProcessPtr() != this)
{
errors.Printf("RunThreadPlan called on wrong process.");
Rename eExecution*** to eExpression*** to be consistent with the result type. llvm-svn: 207945
2014-05-05 10:47:44 +08:00
return eExpressionSetupError;
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 *thread = exe_ctx.GetThreadPtr();
if (thread == NULL)
{
errors.Printf("RunThreadPlan called with invalid thread.");
Rename eExecution*** to eExpression*** to be consistent with the result type. llvm-svn: 207945
2014-05-05 10:47:44 +08:00
return eExpressionSetupError;
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
}
sweep up -Wformat warnings from gcc This is a purely mechanical change explicitly casting any parameters for printf style conversion. This cleans up the warnings emitted by gcc 4.8 on Linux. llvm-svn: 205607
2014-04-04 12:06:10 +08:00
Fix a misunderstanding of the ThreadPlan::OkayToDiscard flag in InferiorCallPOSIX. It was set to true, but all plans run by RunThreadPlan need to have this set to false so they will return control to RunThreadPlan without consulting plans higher on the stack. Since this seems like a common error, I also modified RunThreadPlan to enforce this behavior. <rdar://problem/22543166> llvm-svn: 250084
2015-10-13 03:11:03 +08:00
// We need to change some of the thread plan attributes for the thread plan runner. This will restore them
// when we are done:
RestorePlanState thread_plan_restorer(thread_plan_sp);
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.
sweep up -Wformat warnings from gcc This is a purely mechanical change explicitly casting any parameters for printf style conversion. This cleans up the warnings emitted by gcc 4.8 on Linux. llvm-svn: 205607
2014-04-04 12:06:10 +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
thread_plan_sp->SetPrivate(false);
Fix a misunderstanding of the ThreadPlan::OkayToDiscard flag in InferiorCallPOSIX. It was set to true, but all plans run by RunThreadPlan need to have this set to false so they will return control to RunThreadPlan without consulting plans higher on the stack. Since this seems like a common error, I also modified RunThreadPlan to enforce this behavior. <rdar://problem/22543166> llvm-svn: 250084
2015-10-13 03:11:03 +08:00
// The plans run with RunThreadPlan also need to be terminal master plans or when they are done we will end
// up asking the plan above us whether we should stop, which may give the wrong answer.
thread_plan_sp->SetIsMasterPlan (true);
thread_plan_sp->SetOkayToDiscard(false);
sweep up -Wformat warnings from gcc This is a purely mechanical change explicitly casting any parameters for printf style conversion. This cleans up the warnings emitted by gcc 4.8 on Linux. llvm-svn: 205607
2014-04-04 12:06:10 +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
if (m_private_state.GetValue() != eStateStopped)
{
errors.Printf ("RunThreadPlan called while the private state was not stopped.");
Rename eExecution*** to eExpression*** to be consistent with the result type. llvm-svn: 207945
2014-05-05 10:47:44 +08:00
return eExpressionSetupError;
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
}
sweep up -Wformat warnings from gcc This is a purely mechanical change explicitly casting any parameters for printf style conversion. This cleans up the warnings emitted by gcc 4.8 on Linux. llvm-svn: 205607
2014-04-04 12:06:10 +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();
Roll back the changes I made in r193907 which created a new Frame pure virtual base class and made StackFrame a subclass of that. As I started to build on top of that arrangement today, I found that it wasn't working out like I intended. Instead I'll try sticking with the single StackFrame class -- there's too much code duplication to make a more complicated class hierarchy sensible I think. llvm-svn: 193983
2013-11-04 17:33:30 +08:00
StackFrameSP selected_frame_sp = thread->GetSelectedFrame();
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
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);
Rename eExecution*** to eExpression*** to be consistent with the result type. llvm-svn: 207945
2014-05-05 10:47:44 +08:00
return eExpressionSetupError;
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
}
}
sweep up -Wformat warnings from gcc This is a purely mechanical change explicitly casting any parameters for printf style conversion. This cleans up the warnings emitted by gcc 4.8 on Linux. llvm-svn: 205607
2014-04-04 12:06:10 +08:00
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
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.
sweep up -Wformat warnings from gcc This is a purely mechanical change explicitly casting any parameters for printf style conversion. This cleans up the warnings emitted by gcc 4.8 on Linux. llvm-svn: 205607
2014-04-04 12:06:10 +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
lldb::ThreadSP selected_thread_sp = GetThreadList().GetSelectedThread();
sweep up -Wformat warnings from gcc This is a purely mechanical change explicitly casting any parameters for printf style conversion. This cleans up the warnings emitted by gcc 4.8 on Linux. llvm-svn: 205607
2014-04-04 12:06:10 +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;
}
Create a HostThread abstraction. This patch moves creates a thread abstraction that represents a thread running inside the LLDB process. This is a replacement for otherwise using lldb::thread_t, and provides a platform agnostic interface to managing these threads. Differential Revision: http://reviews.llvm.org/D5198 Reviewed by: Jim Ingham llvm-svn: 217460
2014-09-10 04:54:56 +08:00
HostThread backup_private_state_thread;
Give old_state a default value so we won't try to restore an uninitialized value. In reality the code block that initializes it and the code block that restores it will always match up - but the analyzer doesn't know that and I want to quiet it, so... clang static analyzer fixit. llvm-svn: 219869
2014-10-16 07:39:31 +08:00
lldb::StateType old_state = eStateInvalid;
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::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));
Create a HostThread abstraction. This patch moves creates a thread abstraction that represents a thread running inside the LLDB process. This is a replacement for otherwise using lldb::thread_t, and provides a platform agnostic interface to managing these threads. Differential Revision: http://reviews.llvm.org/D5198 Reviewed by: Jim Ingham llvm-svn: 217460
2014-09-10 04:54:56 +08:00
if (m_private_state_thread.EqualsThread(Host::GetCurrentThread()))
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
{
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);
sweep up -Wformat warnings from gcc This is a purely mechanical change explicitly casting any parameters for printf style conversion. This cleans up the warnings emitted by gcc 4.8 on Linux. llvm-svn: 205607
2014-04-04 12:06:10 +08:00
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
// 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);
}
sweep up -Wformat warnings from gcc This is a purely mechanical change explicitly casting any parameters for printf style conversion. This cleans up the warnings emitted by gcc 4.8 on Linux. llvm-svn: 205607
2014-04-04 12:06:10 +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
thread->QueueThreadPlan(thread_plan_sp, false); // This used to pass "true" does that make sense?
sweep up -Wformat warnings from gcc This is a purely mechanical change explicitly casting any parameters for printf style conversion. This cleans up the warnings emitted by gcc 4.8 on Linux. llvm-svn: 205607
2014-04-04 12:06:10 +08:00
This patch does a couple of things. It completes the job of using EvaluateExpressionOptions consistently throughout the inferior function calling mechanism in lldb begun in Greg's patch r194009. It removes a handful of alternate calls into the ClangUserExpression/ClangFunction/ThreadPlanCallFunction which were there for convenience. Using the EvaluateExpressionOptions removes the need for them. Using that it gets the --debug option from Greg's patch to work cleanly. It also adds another EvaluateExpressionOption to not trap exceptions when running expressions. You shouldn't use this option unless you KNOW your expression can't throw beyond itself. This is: <rdar://problem/15374885> At present this is only available through the SB API's or python. It fixes a bug where function calls would unset the ObjC & C++ exception breakpoints without checking whether they were set by somebody else already. llvm-svn: 194182
2013-11-07 08:11:47 +08:00
if (options.GetDebug())
{
// In this case, we aren't actually going to run, we just want to stop right away.
// Flush this thread so we will refetch the stacks and show the correct backtrace.
// FIXME: To make this prettier we should invent some stop reason for this, but that
// is only cosmetic, and this functionality is only of use to lldb developers who can
// live with not pretty...
thread->Flush();
Rename eExecution*** to eExpression*** to be consistent with the result type. llvm-svn: 207945
2014-05-05 10:47:44 +08:00
return eExpressionStoppedForDebug;
This patch does a couple of things. It completes the job of using EvaluateExpressionOptions consistently throughout the inferior function calling mechanism in lldb begun in Greg's patch r194009. It removes a handful of alternate calls into the ClangUserExpression/ClangFunction/ThreadPlanCallFunction which were there for convenience. Using the EvaluateExpressionOptions removes the need for them. Using that it gets the --debug option from Greg's patch to work cleanly. It also adds another EvaluateExpressionOption to not trap exceptions when running expressions. You shouldn't use this option unless you KNOW your expression can't throw beyond itself. This is: <rdar://problem/15374885> At present this is only available through the SB API's or python. It fixes a bug where function calls would unset the ObjC & C++ exception breakpoints without checking whether they were set by somebody else already. llvm-svn: 194182
2013-11-07 08:11:47 +08:00
}
sweep up -Wformat warnings from gcc This is a purely mechanical change explicitly casting any parameters for printf style conversion. This cleans up the warnings emitted by gcc 4.8 on Linux. llvm-svn: 205607
2014-04-04 12:06:10 +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");
sweep up -Wformat warnings from gcc This is a purely mechanical change explicitly casting any parameters for printf style conversion. This cleans up the warnings emitted by gcc 4.8 on Linux. llvm-svn: 205607
2014-04-04 12:06:10 +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;
sweep up -Wformat warnings from gcc This is a purely mechanical change explicitly casting any parameters for printf style conversion. This cleans up the warnings emitted by gcc 4.8 on Linux. llvm-svn: 205607
2014-04-04 12:06:10 +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.
sweep up -Wformat warnings from gcc This is a purely mechanical change explicitly casting any parameters for printf style conversion. This cleans up the warnings emitted by gcc 4.8 on Linux. llvm-svn: 205607
2014-04-04 12:06:10 +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);
sweep up -Wformat warnings from gcc This is a purely mechanical change explicitly casting any parameters for printf style conversion. This cleans up the warnings emitted by gcc 4.8 on Linux. llvm-svn: 205607
2014-04-04 12:06:10 +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)
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());
}
sweep up -Wformat warnings from gcc This is a purely mechanical change explicitly casting any parameters for printf style conversion. This cleans up the warnings emitted by gcc 4.8 on Linux. llvm-svn: 205607
2014-04-04 12:06:10 +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 got_event;
lldb::EventSP event_sp;
lldb::StateType stop_state = lldb::eStateInvalid;
sweep up -Wformat warnings from gcc This is a purely mechanical change explicitly casting any parameters for printf style conversion. This cleans up the warnings emitted by gcc 4.8 on Linux. llvm-svn: 205607
2014-04-04 12:06:10 +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
TimeValue* timeout_ptr = NULL;
TimeValue real_timeout;
sweep up -Wformat warnings from gcc This is a purely mechanical change explicitly casting any parameters for printf style conversion. This cleans up the warnings emitted by gcc 4.8 on Linux. llvm-svn: 205607
2014-04-04 12:06:10 +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 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;
sweep up -Wformat warnings from gcc This is a purely mechanical change explicitly casting any parameters for printf style conversion. This cleans up the warnings emitted by gcc 4.8 on Linux. llvm-svn: 205607
2014-04-04 12:06:10 +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;
sweep up -Wformat warnings from gcc This is a purely mechanical change explicitly casting any parameters for printf style conversion. This cleans up the warnings emitted by gcc 4.8 on Linux. llvm-svn: 205607
2014-04-04 12:06:10 +08:00
This patch does a couple of things. It completes the job of using EvaluateExpressionOptions consistently throughout the inferior function calling mechanism in lldb begun in Greg's patch r194009. It removes a handful of alternate calls into the ClangUserExpression/ClangFunction/ThreadPlanCallFunction which were there for convenience. Using the EvaluateExpressionOptions removes the need for them. Using that it gets the --debug option from Greg's patch to work cleanly. It also adds another EvaluateExpressionOption to not trap exceptions when running expressions. You shouldn't use this option unless you KNOW your expression can't throw beyond itself. This is: <rdar://problem/15374885> At present this is only available through the SB API's or python. It fixes a bug where function calls would unset the ObjC & C++ exception breakpoints without checking whether they were set by somebody else already. llvm-svn: 194182
2013-11-07 08:11:47 +08:00
uint32_t timeout_usec = options.GetTimeoutUsec();
Make RunThreadPlan start the timeout clock for each part of the expression evaluation AFTER the successful resume for that part. This will make the timeouts more stable when lldb is running in a busy program. llvm-svn: 206835
2014-04-22 09:41:52 +08:00
uint32_t one_thread_timeout_usec;
uint32_t all_threads_timeout_usec = 0;
Clean up the logic in setting timeouts a bit, and the logging as well. llvm-svn: 206351
2014-04-16 10:24:48 +08:00
// If we are going to run all threads the whole time, or if we are only going to run one thread,
// then we don't need the first timeout. So we set the final timeout, and pretend we are after the
// first timeout already.
if (!options.GetStopOthers() || !options.GetTryAllThreads())
Plumb the EvaluateExpressionOptions::{Set,Get}StopOthers through the SB API, and make it work in RunThreadPlan. Also remove SetStopOthers from the ThreadPlanCallFunction, because if the value you have doesn't match what is in the EvaluateExpressionOptions the plan was passed when created it won't work correctly. llvm-svn: 202464
2014-02-28 10:52:06 +08:00
{
before_first_timeout = false;
Make RunThreadPlan start the timeout clock for each part of the expression evaluation AFTER the successful resume for that part. This will make the timeouts more stable when lldb is running in a busy program. llvm-svn: 206835
2014-04-22 09:41:52 +08:00
one_thread_timeout_usec = 0;
all_threads_timeout_usec = timeout_usec;
Plumb the EvaluateExpressionOptions::{Set,Get}StopOthers through the SB API, and make it work in RunThreadPlan. Also remove SetStopOthers from the ThreadPlanCallFunction, because if the value you have doesn't match what is in the EvaluateExpressionOptions the plan was passed when created it won't work correctly. llvm-svn: 202464
2014-02-28 10:52:06 +08:00
}
Clean up the logic in setting timeouts a bit, and the logging as well. llvm-svn: 206351
2014-04-16 10:24: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
{
Make RunThreadPlan start the timeout clock for each part of the expression evaluation AFTER the successful resume for that part. This will make the timeouts more stable when lldb is running in a busy program. llvm-svn: 206835
2014-04-22 09:41:52 +08:00
uint32_t option_one_thread_timeout = options.GetOneThreadTimeoutUsec();
sweep up -Wformat warnings from gcc This is a purely mechanical change explicitly casting any parameters for printf style conversion. This cleans up the warnings emitted by gcc 4.8 on Linux. llvm-svn: 205607
2014-04-04 12:06:10 +08:00
Add the ability from the SB API's to set the "one thread" timeout for expression evaluations that try one and then all threads. <rdar://problem/15598528> llvm-svn: 205060
2014-03-29 05:58:28 +08:00
// If the overall wait is forever, then we only need to set the one thread timeout:
if (timeout_usec == 0)
{
Fix one thread timeout logic This should fix the seemingly-random failures observed on the FreeBSD buildbot. llvm-svn: 205241
2014-04-01 03:28:14 +08:00
if (option_one_thread_timeout != 0)
Make RunThreadPlan start the timeout clock for each part of the expression evaluation AFTER the successful resume for that part. This will make the timeouts more stable when lldb is running in a busy program. llvm-svn: 206835
2014-04-22 09:41:52 +08:00
one_thread_timeout_usec = option_one_thread_timeout;
Add the ability from the SB API's to set the "one thread" timeout for expression evaluations that try one and then all threads. <rdar://problem/15598528> llvm-svn: 205060
2014-03-29 05:58:28 +08:00
else
Make RunThreadPlan start the timeout clock for each part of the expression evaluation AFTER the successful resume for that part. This will make the timeouts more stable when lldb is running in a busy program. llvm-svn: 206835
2014-04-22 09:41:52 +08:00
one_thread_timeout_usec = default_one_thread_timeout_usec;
Add the ability from the SB API's to set the "one thread" timeout for expression evaluations that try one and then all threads. <rdar://problem/15598528> llvm-svn: 205060
2014-03-29 05:58:28 +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
{
Add the ability from the SB API's to set the "one thread" timeout for expression evaluations that try one and then all threads. <rdar://problem/15598528> llvm-svn: 205060
2014-03-29 05:58:28 +08:00
// Otherwise, if the one thread timeout is set, make sure it isn't longer than the overall timeout,
// and use it, otherwise use half the total timeout, bounded by the default_one_thread_timeout_usec.
uint64_t computed_one_thread_timeout;
if (option_one_thread_timeout != 0)
{
if (timeout_usec < option_one_thread_timeout)
{
errors.Printf("RunThreadPlan called without one thread timeout greater than total timeout");
Rename eExecution*** to eExpression*** to be consistent with the result type. llvm-svn: 207945
2014-05-05 10:47:44 +08:00
return eExpressionSetupError;
Add the ability from the SB API's to set the "one thread" timeout for expression evaluations that try one and then all threads. <rdar://problem/15598528> llvm-svn: 205060
2014-03-29 05:58:28 +08:00
}
computed_one_thread_timeout = option_one_thread_timeout;
}
else
{
computed_one_thread_timeout = timeout_usec / 2;
if (computed_one_thread_timeout > default_one_thread_timeout_usec)
computed_one_thread_timeout = default_one_thread_timeout_usec;
}
Make RunThreadPlan start the timeout clock for each part of the expression evaluation AFTER the successful resume for that part. This will make the timeouts more stable when lldb is running in a busy program. llvm-svn: 206835
2014-04-22 09:41:52 +08:00
one_thread_timeout_usec = computed_one_thread_timeout;
all_threads_timeout_usec = timeout_usec - one_thread_timeout_usec;
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
}
}
Clean up the logic in setting timeouts a bit, and the logging as well. llvm-svn: 206351
2014-04-16 10:24:48 +08:00
if (log)
Make RunThreadPlan start the timeout clock for each part of the expression evaluation AFTER the successful resume for that part. This will make the timeouts more stable when lldb is running in a busy program. llvm-svn: 206835
2014-04-22 09:41:52 +08:00
log->Printf ("Stop others: %u, try all: %u, before_first: %u, one thread: %" PRIu32 " - all threads: %" PRIu32 ".\n",
Clean up the logic in setting timeouts a bit, and the logging as well. llvm-svn: 206351
2014-04-16 10:24:48 +08:00
options.GetStopOthers(),
options.GetTryAllThreads(),
Make RunThreadPlan start the timeout clock for each part of the expression evaluation AFTER the successful resume for that part. This will make the timeouts more stable when lldb is running in a busy program. llvm-svn: 206835
2014-04-22 09:41:52 +08:00
before_first_timeout,
one_thread_timeout_usec,
all_threads_timeout_usec);
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
Get the breakpoint setting, and the Mac OS X DYLD trampolines and expression evaluator to handle Indirect symbols correctly. There were a couple of pieces to this. 1) When a breakpoint location finds itself pointing to an Indirect symbol, when the site for it is created it needs to resolve the symbol and actually set the site at its target. 2) Not all breakpoints want to do this (i.e. a straight address breakpoint should always set itself on the specified address, so somem machinery was needed to specify that. 3) I added some info to the break list output for indirect symbols so you could see what was happening. Also I made it clear when we re-route through re-exported symbols. 4) I moved ResolveIndirectFunction from ProcessPosix to Process since it works the exact same way on Mac OS X and the other posix systems. If we find a platform that doesn't do it this way, they can override the call in Process. 5) Fixed one bug in RunThreadPlan, if you were trying to run a thread plan after a "running" event had been broadcast, the event coalescing would cause you to miss the ThreadPlan running event. So I added a way to override the coalescing. 6) Made DynamicLoaderMacOSXDYLD::GetStepThroughTrampolinePlan handle Indirect & Re-exported symbols. <rdar://problem/15280639> llvm-svn: 198976
2014-01-11 07:46:59 +08:00
// This isn't going to work if there are unfetched events on the queue.
// Are there cases where we might want to run the remaining events here, and then try to
// call the function? That's probably being too tricky for our own good.
sweep up -Wformat warnings from gcc This is a purely mechanical change explicitly casting any parameters for printf style conversion. This cleans up the warnings emitted by gcc 4.8 on Linux. llvm-svn: 205607
2014-04-04 12:06:10 +08:00
Get the breakpoint setting, and the Mac OS X DYLD trampolines and expression evaluator to handle Indirect symbols correctly. There were a couple of pieces to this. 1) When a breakpoint location finds itself pointing to an Indirect symbol, when the site for it is created it needs to resolve the symbol and actually set the site at its target. 2) Not all breakpoints want to do this (i.e. a straight address breakpoint should always set itself on the specified address, so somem machinery was needed to specify that. 3) I added some info to the break list output for indirect symbols so you could see what was happening. Also I made it clear when we re-route through re-exported symbols. 4) I moved ResolveIndirectFunction from ProcessPosix to Process since it works the exact same way on Mac OS X and the other posix systems. If we find a platform that doesn't do it this way, they can override the call in Process. 5) Fixed one bug in RunThreadPlan, if you were trying to run a thread plan after a "running" event had been broadcast, the event coalescing would cause you to miss the ThreadPlan running event. So I added a way to override the coalescing. 6) Made DynamicLoaderMacOSXDYLD::GetStepThroughTrampolinePlan handle Indirect & Re-exported symbols. <rdar://problem/15280639> llvm-svn: 198976
2014-01-11 07:46:59 +08:00
Event *other_events = listener.PeekAtNextEvent();
if (other_events != NULL)
{
errors.Printf("Calling RunThreadPlan with pending events on the queue.");
Rename eExecution*** to eExpression*** to be consistent with the result type. llvm-svn: 207945
2014-05-05 10:47:44 +08:00
return eExpressionSetupError;
Get the breakpoint setting, and the Mac OS X DYLD trampolines and expression evaluator to handle Indirect symbols correctly. There were a couple of pieces to this. 1) When a breakpoint location finds itself pointing to an Indirect symbol, when the site for it is created it needs to resolve the symbol and actually set the site at its target. 2) Not all breakpoints want to do this (i.e. a straight address breakpoint should always set itself on the specified address, so somem machinery was needed to specify that. 3) I added some info to the break list output for indirect symbols so you could see what was happening. Also I made it clear when we re-route through re-exported symbols. 4) I moved ResolveIndirectFunction from ProcessPosix to Process since it works the exact same way on Mac OS X and the other posix systems. If we find a platform that doesn't do it this way, they can override the call in Process. 5) Fixed one bug in RunThreadPlan, if you were trying to run a thread plan after a "running" event had been broadcast, the event coalescing would cause you to miss the ThreadPlan running event. So I added a way to override the coalescing. 6) Made DynamicLoaderMacOSXDYLD::GetStepThroughTrampolinePlan handle Indirect & Re-exported symbols. <rdar://problem/15280639> llvm-svn: 198976
2014-01-11 07:46:59 +08:00
}
sweep up -Wformat warnings from gcc This is a purely mechanical change explicitly casting any parameters for printf style conversion. This cleans up the warnings emitted by gcc 4.8 on Linux. llvm-svn: 205607
2014-04-04 12:06:10 +08:00
Get the breakpoint setting, and the Mac OS X DYLD trampolines and expression evaluator to handle Indirect symbols correctly. There were a couple of pieces to this. 1) When a breakpoint location finds itself pointing to an Indirect symbol, when the site for it is created it needs to resolve the symbol and actually set the site at its target. 2) Not all breakpoints want to do this (i.e. a straight address breakpoint should always set itself on the specified address, so somem machinery was needed to specify that. 3) I added some info to the break list output for indirect symbols so you could see what was happening. Also I made it clear when we re-route through re-exported symbols. 4) I moved ResolveIndirectFunction from ProcessPosix to Process since it works the exact same way on Mac OS X and the other posix systems. If we find a platform that doesn't do it this way, they can override the call in Process. 5) Fixed one bug in RunThreadPlan, if you were trying to run a thread plan after a "running" event had been broadcast, the event coalescing would cause you to miss the ThreadPlan running event. So I added a way to override the coalescing. 6) Made DynamicLoaderMacOSXDYLD::GetStepThroughTrampolinePlan handle Indirect & Re-exported symbols. <rdar://problem/15280639> llvm-svn: 198976
2014-01-11 07:46:59 +08:00
// We also need to make sure that the next event is delivered. We might be calling a function as part of
// a thread plan, in which case the last delivered event could be the running event, and we don't want
// event coalescing to cause us to lose OUR running event...
ForceNextEventDelivery();
sweep up -Wformat warnings from gcc This is a purely mechanical change explicitly casting any parameters for printf style conversion. This cleans up the warnings emitted by gcc 4.8 on Linux. llvm-svn: 205607
2014-04-04 12:06:10 +08:00
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.
Fix the behavior when hand-calling a function times out on one thread, but by the time we go to halt, it has already stopped by hitting the function end breakpoint. That wasn't being shown to the threads so the Function call thread plan didn't know its job was done. <rdar://problem/16515785> llvm-svn: 205803
2014-04-09 05:33:21 +08:00
#ifdef LLDB_RUN_THREAD_HALT_WITH_EVENT
// It's pretty much impossible to write test cases for things like:
// One thread timeout expires, I go to halt, but the process already stopped
// on the function call stop breakpoint. Turning on this define will make us not
// fetch the first event till after the halt. So if you run a quick function, it will have
// completed, and the completion event will be waiting, when you interrupt for halt.
// The expression evaluation should still succeed.
bool miss_first_event = true;
#endif
Make RunThreadPlan start the timeout clock for each part of the expression evaluation AFTER the successful resume for that part. This will make the timeouts more stable when lldb is running in a busy program. llvm-svn: 206835
2014-04-22 09:41:52 +08:00
TimeValue one_thread_timeout;
TimeValue final_timeout;
Fix Clang-tidy modernize-use-override warnings in source/Target; other minor fixes. llvm-svn: 251134
2015-10-24 02:39:37 +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 (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);
sweep up -Wformat warnings from gcc This is a purely mechanical change explicitly casting any parameters for printf style conversion. This cleans up the warnings emitted by gcc 4.8 on Linux. llvm-svn: 205607
2014-04-04 12:06:10 +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.
sweep up -Wformat warnings from gcc This is a purely mechanical change explicitly casting any parameters for printf style conversion. This cleans up the warnings emitted by gcc 4.8 on Linux. llvm-svn: 205607
2014-04-04 12:06:10 +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)
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());
Rename eExecution*** to eExpression*** to be consistent with the result type. llvm-svn: 207945
2014-05-05 10:47:44 +08:00
return_value = eExpressionSetupError;
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
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
}
sweep up -Wformat warnings from gcc This is a purely mechanical change explicitly casting any parameters for printf style conversion. This cleans up the warnings emitted by gcc 4.8 on Linux. llvm-svn: 205607
2014-04-04 12:06:10 +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);
sweep up -Wformat warnings from gcc This is a purely mechanical change explicitly casting any parameters for printf style conversion. This cleans up the warnings emitted by gcc 4.8 on Linux. llvm-svn: 205607
2014-04-04 12:06:10 +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(&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);
Rename eExecution*** to eExpression*** to be consistent with the result type. llvm-svn: 207945
2014-05-05 10:47:44 +08:00
return_value = eExpressionSetupError;
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;
}
sweep up -Wformat warnings from gcc This is a purely mechanical change explicitly casting any parameters for printf style conversion. This cleans up the warnings emitted by gcc 4.8 on Linux. llvm-svn: 205607
2014-04-04 12:06:10 +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
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;
sweep up -Wformat warnings from gcc This is a purely mechanical change explicitly casting any parameters for printf style conversion. This cleans up the warnings emitted by gcc 4.8 on Linux. llvm-svn: 205607
2014-04-04 12:06:10 +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 == 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);
}
sweep up -Wformat warnings from gcc This is a purely mechanical change explicitly casting any parameters for printf style conversion. This cleans up the warnings emitted by gcc 4.8 on Linux. llvm-svn: 205607
2014-04-04 12:06:10 +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 (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.
Recommit "Fix race during process interruption" This is a resubmit of r254403, see that commit's message for context. This fixes an issue in the original commit, where we would incorrectly interrupt the process if the interrupt request came just as we were about to send the stopped event to the public. llvm-svn: 254902
2015-12-07 20:36:52 +08:00
const bool clear_thread_plans = false;
const bool use_run_lock = false;
Halt(clear_thread_plans, use_run_lock);
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
}
sweep up -Wformat warnings from gcc This is a purely mechanical change explicitly casting any parameters for printf style conversion. This cleans up the warnings emitted by gcc 4.8 on Linux. llvm-svn: 205607
2014-04-04 12:06:10 +08:00
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));
Rename eExecution*** to eExpression*** to be consistent with the result type. llvm-svn: 207945
2014-05-05 10:47:44 +08:00
return_value = eExpressionSetupError;
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;
}
sweep up -Wformat warnings from gcc This is a purely mechanical change explicitly casting any parameters for printf style conversion. This cleans up the warnings emitted by gcc 4.8 on Linux. llvm-svn: 205607
2014-04-04 12:06:10 +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 (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.");
}
sweep up -Wformat warnings from gcc This is a purely mechanical change explicitly casting any parameters for printf style conversion. This cleans up the warnings emitted by gcc 4.8 on Linux. llvm-svn: 205607
2014-04-04 12:06:10 +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)
{
This patch does a couple of things. It completes the job of using EvaluateExpressionOptions consistently throughout the inferior function calling mechanism in lldb begun in Greg's patch r194009. It removes a handful of alternate calls into the ClangUserExpression/ClangFunction/ThreadPlanCallFunction which were there for convenience. Using the EvaluateExpressionOptions removes the need for them. Using that it gets the --debug option from Greg's patch to work cleanly. It also adds another EvaluateExpressionOption to not trap exceptions when running expressions. You shouldn't use this option unless you KNOW your expression can't throw beyond itself. This is: <rdar://problem/15374885> At present this is only available through the SB API's or python. It fixes a bug where function calls would unset the ObjC & C++ exception breakpoints without checking whether they were set by somebody else already. llvm-svn: 194182
2013-11-07 08:11:47 +08:00
if (options.GetTryAllThreads())
Make RunThreadPlan start the timeout clock for each part of the expression evaluation AFTER the successful resume for that part. This will make the timeouts more stable when lldb is running in a busy program. llvm-svn: 206835
2014-04-22 09:41:52 +08:00
{
one_thread_timeout = TimeValue::Now();
one_thread_timeout.OffsetWithMicroSeconds(one_thread_timeout_usec);
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
timeout_ptr = &one_thread_timeout;
Make RunThreadPlan start the timeout clock for each part of the expression evaluation AFTER the successful resume for that part. This will make the timeouts more stable when lldb is running in a busy program. llvm-svn: 206835
2014-04-22 09:41:52 +08:00
}
<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
Make RunThreadPlan start the timeout clock for each part of the expression evaluation AFTER the successful resume for that part. This will make the timeouts more stable when lldb is running in a busy program. llvm-svn: 206835
2014-04-22 09:41:52 +08:00
{
final_timeout = TimeValue::Now();
final_timeout.OffsetWithMicroSeconds (timeout_usec);
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
timeout_ptr = &final_timeout;
Make RunThreadPlan start the timeout clock for each part of the expression evaluation AFTER the successful resume for that part. This will make the timeouts more stable when lldb is running in a busy program. llvm-svn: 206835
2014-04-22 09:41:52 +08:00
}
<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
Make RunThreadPlan start the timeout clock for each part of the expression evaluation AFTER the successful resume for that part. This will make the timeouts more stable when lldb is running in a busy program. llvm-svn: 206835
2014-04-22 09:41:52 +08:00
{
final_timeout = TimeValue::Now();
final_timeout.OffsetWithMicroSeconds (all_threads_timeout_usec);
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
timeout_ptr = &final_timeout;
Make RunThreadPlan start the timeout clock for each part of the expression evaluation AFTER the successful resume for that part. This will make the timeouts more stable when lldb is running in a busy program. llvm-svn: 206835
2014-04-22 09:41:52 +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
}
sweep up -Wformat warnings from gcc This is a purely mechanical change explicitly casting any parameters for printf style conversion. This cleans up the warnings emitted by gcc 4.8 on Linux. llvm-svn: 205607
2014-04-04 12:06:10 +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;
sweep up -Wformat warnings from gcc This is a purely mechanical change explicitly casting any parameters for printf style conversion. This cleans up the warnings emitted by gcc 4.8 on Linux. llvm-svn: 205607
2014-04-04 12:06:10 +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
// 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
}
Fix the behavior when hand-calling a function times out on one thread, but by the time we go to halt, it has already stopped by hitting the function end breakpoint. That wasn't being shown to the threads so the Function call thread plan didn't know its job was done. <rdar://problem/16515785> llvm-svn: 205803
2014-04-09 05:33:21 +08:00
#ifdef LLDB_RUN_THREAD_HALT_WITH_EVENT
// See comment above...
if (miss_first_event)
{
usleep(1000);
miss_first_event = false;
got_event = false;
}
else
#endif
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);
sweep up -Wformat warnings from gcc This is a purely mechanical change explicitly casting any parameters for printf style conversion. This cleans up the warnings emitted by gcc 4.8 on Linux. llvm-svn: 205607
2014-04-04 12:06:10 +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 (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
{
Recommit "Fix race during process interruption" This is a resubmit of r254403, see that commit's message for context. This fixes an issue in the original commit, where we would incorrectly interrupt the process if the interrupt request came just as we were about to send the stopped event to the public. llvm-svn: 254902
2015-12-07 20:36:52 +08:00
const bool clear_thread_plans = false;
const bool use_run_lock = false;
Halt(clear_thread_plans, use_run_lock);
Rename eExecution*** to eExpression*** to be consistent with the result type. llvm-svn: 207945
2014-05-05 10:47:44 +08:00
return_value = eExpressionInterrupted;
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
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));
sweep up -Wformat warnings from gcc This is a purely mechanical change explicitly casting any parameters for printf style conversion. This cleans up the warnings emitted by gcc 4.8 on Linux. llvm-svn: 205607
2014-04-04 12:06:10 +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
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);
Rename eExecution*** to eExpression*** to be consistent with the result type. llvm-svn: 207945
2014-05-05 10:47:44 +08:00
return_value = eExpressionInterrupted;
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();
sweep up -Wformat warnings from gcc This is a purely mechanical change explicitly casting any parameters for printf style conversion. This cleans up the warnings emitted by gcc 4.8 on Linux. llvm-svn: 205607
2014-04-04 12:06:10 +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
// 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.");
Fix a misunderstanding of the ThreadPlan::OkayToDiscard flag in InferiorCallPOSIX. It was set to true, but all plans run by RunThreadPlan need to have this set to false so they will return control to RunThreadPlan without consulting plans higher on the stack. Since this seems like a common error, I also modified RunThreadPlan to enforce this behavior. <rdar://problem/22543166> llvm-svn: 250084
2015-10-13 03:11:03 +08:00
// Restore the plan state so it will get reported as intended when we are done.
thread_plan_restorer.Clean();
Rename eExecution*** to eExpression*** to be consistent with the result type. llvm-svn: 207945
2014-05-05 10:47:44 +08:00
return_value = eExpressionCompleted;
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());
Rename eExecution*** to eExpression*** to be consistent with the result type. llvm-svn: 207945
2014-05-05 10:47:44 +08:00
return_value = eExpressionHitBreakpoint;
This patch does a couple of things. It completes the job of using EvaluateExpressionOptions consistently throughout the inferior function calling mechanism in lldb begun in Greg's patch r194009. It removes a handful of alternate calls into the ClangUserExpression/ClangFunction/ThreadPlanCallFunction which were there for convenience. Using the EvaluateExpressionOptions removes the need for them. Using that it gets the --debug option from Greg's patch to work cleanly. It also adds another EvaluateExpressionOption to not trap exceptions when running expressions. You shouldn't use this option unless you KNOW your expression can't throw beyond itself. This is: <rdar://problem/15374885> At present this is only available through the SB API's or python. It fixes a bug where function calls would unset the ObjC & C++ exception breakpoints without checking whether they were set by somebody else already. llvm-svn: 194182
2013-11-07 08:11:47 +08:00
if (!options.DoesIgnoreBreakpoints())
Send a stop event when an expression stops at a breakpoint in an expression and doesn't ignore the stop. Patch by Jim Ingham. <rdar://problem/14583884> llvm-svn: 187434
2013-07-31 03:54:09 +08:00
{
Fix a misunderstanding of the ThreadPlan::OkayToDiscard flag in InferiorCallPOSIX. It was set to true, but all plans run by RunThreadPlan need to have this set to false so they will return control to RunThreadPlan without consulting plans higher on the stack. Since this seems like a common error, I also modified RunThreadPlan to enforce this behavior. <rdar://problem/22543166> llvm-svn: 250084
2015-10-13 03:11:03 +08:00
// Restore the plan state and then force Private to false. We are
// going to stop because of this plan so we need it to become a public
// plan or it won't report correctly when we continue to its termination
// later on.
thread_plan_restorer.Clean();
if (thread_plan_sp)
thread_plan_sp->SetPrivate(false);
Send a stop event when an expression stops at a breakpoint in an expression and doesn't ignore the stop. Patch by Jim Ingham. <rdar://problem/14583884> llvm-svn: 187434
2013-07-31 03:54:09 +08:00
event_to_broadcast_sp = 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
}
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.");
This patch does a couple of things. It completes the job of using EvaluateExpressionOptions consistently throughout the inferior function calling mechanism in lldb begun in Greg's patch r194009. It removes a handful of alternate calls into the ClangUserExpression/ClangFunction/ThreadPlanCallFunction which were there for convenience. Using the EvaluateExpressionOptions removes the need for them. Using that it gets the --debug option from Greg's patch to work cleanly. It also adds another EvaluateExpressionOption to not trap exceptions when running expressions. You shouldn't use this option unless you KNOW your expression can't throw beyond itself. This is: <rdar://problem/15374885> At present this is only available through the SB API's or python. It fixes a bug where function calls would unset the ObjC & C++ exception breakpoints without checking whether they were set by somebody else already. llvm-svn: 194182
2013-11-07 08:11:47 +08:00
if (!options.DoesUnwindOnError())
Send a stop event when an expression stops at a breakpoint in an expression and doesn't ignore the stop. Patch by Jim Ingham. <rdar://problem/14583884> llvm-svn: 187434
2013-07-31 03:54:09 +08:00
event_to_broadcast_sp = event_sp;
Rename eExecution*** to eExpression*** to be consistent with the result type. llvm-svn: 207945
2014-05-05 10:47:44 +08:00
return_value = eExpressionInterrupted;
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));
sweep up -Wformat warnings from gcc This is a purely mechanical change explicitly casting any parameters for printf style conversion. This cleans up the warnings emitted by gcc 4.8 on Linux. llvm-svn: 205607
2014-04-04 12:06:10 +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 (stop_state == eStateExited)
event_to_broadcast_sp = event_sp;
sweep up -Wformat warnings from gcc This is a purely mechanical change explicitly casting any parameters for printf style conversion. This cleans up the warnings emitted by gcc 4.8 on Linux. llvm-svn: 205607
2014-04-04 12:06:10 +08:00
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");
Rename eExecution*** to eExpression*** to be consistent with the result type. llvm-svn: 207945
2014-05-05 10:47:44 +08:00
return_value = eExpressionInterrupted;
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;
}
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
}
sweep up -Wformat warnings from gcc This is a purely mechanical change explicitly casting any parameters for printf style conversion. This cleans up the warnings emitted by gcc 4.8 on Linux. llvm-svn: 205607
2014-04-04 12:06:10 +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...");
Rename eExecution*** to eExpression*** to be consistent with the result type. llvm-svn: 207945
2014-05-05 10:47:44 +08:00
return_value = eExpressionInterrupted;
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.
sweep up -Wformat warnings from gcc This is a purely mechanical change explicitly casting any parameters for printf style conversion. This cleans up the warnings emitted by gcc 4.8 on Linux. llvm-svn: 205607
2014-04-04 12:06:10 +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) {
This patch does a couple of things. It completes the job of using EvaluateExpressionOptions consistently throughout the inferior function calling mechanism in lldb begun in Greg's patch r194009. It removes a handful of alternate calls into the ClangUserExpression/ClangFunction/ThreadPlanCallFunction which were there for convenience. Using the EvaluateExpressionOptions removes the need for them. Using that it gets the --debug option from Greg's patch to work cleanly. It also adds another EvaluateExpressionOption to not trap exceptions when running expressions. You shouldn't use this option unless you KNOW your expression can't throw beyond itself. This is: <rdar://problem/15374885> At present this is only available through the SB API's or python. It fixes a bug where function calls would unset the ObjC & C++ exception breakpoints without checking whether they were set by somebody else already. llvm-svn: 194182
2013-11-07 08:11:47 +08:00
if (options.GetTryAllThreads())
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 (before_first_timeout)
Clean up the logic in setting timeouts a bit, and the logging as well. llvm-svn: 206351
2014-04-16 10:24:48 +08:00
{
if (timeout_usec != 0)
{
log->Printf ("Process::RunThreadPlan(): Running function with one thread timeout timed out, "
Make RunThreadPlan start the timeout clock for each part of the expression evaluation AFTER the successful resume for that part. This will make the timeouts more stable when lldb is running in a busy program. llvm-svn: 206835
2014-04-22 09:41:52 +08:00
"running for %" PRIu32 " usec with all threads enabled.",
all_threads_timeout_usec);
Clean up the logic in setting timeouts a bit, and the logging as well. llvm-svn: 206351
2014-04-16 10:24:48 +08:00
}
else
{
log->Printf ("Process::RunThreadPlan(): Running function with one thread timeout timed out, "
Typo: forever is one word llvm-svn: 207564
2014-04-30 01:48:06 +08:00
"running forever with all threads enabled.");
Clean up the logic in setting timeouts a bit, and the logging as well. llvm-svn: 206351
2014-04-16 10:24:48 +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
log->Printf ("Process::RunThreadPlan(): Restarting function with all threads enabled "
Fix the signed-ness of a few log printf directives in Process::RunThreadPlan. llvm-svn: 193488
2013-10-27 10:32:23 +08:00
"and timeout: %u timed out, abandoning execution.",
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
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
Fix the signed-ness of a few log printf directives in Process::RunThreadPlan. llvm-svn: 193488
2013-10-27 10:32:23 +08:00
log->Printf ("Process::RunThreadPlan(): Running function with timeout: %u 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
}
sweep up -Wformat warnings from gcc This is a purely mechanical change explicitly casting any parameters for printf style conversion. This cleans up the warnings emitted by gcc 4.8 on Linux. llvm-svn: 205607
2014-04-04 12:06:10 +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.
sweep up -Wformat warnings from gcc This is a purely mechanical change explicitly casting any parameters for printf style conversion. This cleans up the warnings emitted by gcc 4.8 on Linux. llvm-svn: 205607
2014-04-04 12:06:10 +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 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.");
Recommit "Fix race during process interruption" This is a resubmit of r254403, see that commit's message for context. This fixes an issue in the original commit, where we would incorrectly interrupt the process if the interrupt request came just as we were about to send the stopped event to the public. llvm-svn: 254902
2015-12-07 20:36:52 +08:00
const bool clear_thread_plans = false;
const bool use_run_lock = false;
Halt(clear_thread_plans, use_run_lock);
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.");
sweep up -Wformat warnings from gcc This is a purely mechanical change explicitly casting any parameters for printf style conversion. This cleans up the warnings emitted by gcc 4.8 on Linux. llvm-svn: 205607
2014-04-04 12:06:10 +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);
sweep up -Wformat warnings from gcc This is a purely mechanical change explicitly casting any parameters for printf style conversion. This cleans up the warnings emitted by gcc 4.8 on Linux. llvm-svn: 205607
2014-04-04 12:06:10 +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 (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
}
sweep up -Wformat warnings from gcc This is a purely mechanical change explicitly casting any parameters for printf style conversion. This cleans up the warnings emitted by gcc 4.8 on Linux. llvm-svn: 205607
2014-04-04 12:06:10 +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:
sweep up -Wformat warnings from gcc This is a purely mechanical change explicitly casting any parameters for printf style conversion. This cleans up the warnings emitted by gcc 4.8 on Linux. llvm-svn: 205607
2014-04-04 12:06:10 +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 (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.");
Rename eExecution*** to eExpression*** to be consistent with the result type. llvm-svn: 207945
2014-05-05 10:47:44 +08:00
return_value = eExpressionCompleted;
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;
}
sweep up -Wformat warnings from gcc This is a purely mechanical change explicitly casting any parameters for printf style conversion. This cleans up the warnings emitted by gcc 4.8 on Linux. llvm-svn: 205607
2014-04-04 12:06:10 +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 (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;
}
This patch does a couple of things. It completes the job of using EvaluateExpressionOptions consistently throughout the inferior function calling mechanism in lldb begun in Greg's patch r194009. It removes a handful of alternate calls into the ClangUserExpression/ClangFunction/ThreadPlanCallFunction which were there for convenience. Using the EvaluateExpressionOptions removes the need for them. Using that it gets the --debug option from Greg's patch to work cleanly. It also adds another EvaluateExpressionOption to not trap exceptions when running expressions. You shouldn't use this option unless you KNOW your expression can't throw beyond itself. This is: <rdar://problem/15374885> At present this is only available through the SB API's or python. It fixes a bug where function calls would unset the ObjC & C++ exception breakpoints without checking whether they were set by somebody else already. llvm-svn: 194182
2013-11-07 08:11:47 +08:00
if (!options.GetTryAllThreads())
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(): try_all_threads was false, we stopped so now we're quitting.");
Rename eExecution*** to eExpression*** to be consistent with the result type. llvm-svn: 207945
2014-05-05 10:47:44 +08:00
return_value = eExpressionInterrupted;
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;
}
sweep up -Wformat warnings from gcc This is a purely mechanical change explicitly casting any parameters for printf style conversion. This cleans up the warnings emitted by gcc 4.8 on Linux. llvm-svn: 205607
2014-04-04 12:06:10 +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)
{
// 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.");
Rename eExecution*** to eExpression*** to be consistent with the result type. llvm-svn: 207945
2014-05-05 10:47:44 +08:00
return_value = eExpressionInterrupted;
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;
}
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.");
Rename eExecution*** to eExpression*** to be consistent with the result type. llvm-svn: 207945
2014-05-05 10:47:44 +08:00
return_value = eExpressionInterrupted;
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
}
sweep up -Wformat warnings from gcc This is a purely mechanical change explicitly casting any parameters for printf style conversion. This cleans up the warnings emitted by gcc 4.8 on Linux. llvm-svn: 205607
2014-04-04 12:06:10 +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
sweep up -Wformat warnings from gcc This is a purely mechanical change explicitly casting any parameters for printf style conversion. This cleans up the warnings emitted by gcc 4.8 on Linux. llvm-svn: 205607
2014-04-04 12:06:10 +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.
Fix up the HostThread interface, making the interface simpler. Reviewed by: Greg Clayton Differential Revision: http://reviews.llvm.org/D5417 llvm-svn: 218325
2014-09-24 02:32:09 +08:00
if (backup_private_state_thread.IsJoinable())
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
}
Give old_state a default value so we won't try to restore an uninitialized value. In reality the code block that initializes it and the code block that restores it will always match up - but the analyzer doesn't know that and I want to quiet it, so... clang static analyzer fixit. llvm-svn: 219869
2014-10-16 07:39:31 +08:00
if (old_state != eStateInvalid)
m_public_state.SetValueNoLock(old_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
}
sweep up -Wformat warnings from gcc This is a purely mechanical change explicitly casting any parameters for printf style conversion. This cleans up the warnings emitted by gcc 4.8 on Linux. llvm-svn: 205607
2014-04-04 12:06:10 +08:00
Fix a misunderstanding of the ThreadPlan::OkayToDiscard flag in InferiorCallPOSIX. It was set to true, but all plans run by RunThreadPlan need to have this set to false so they will return control to RunThreadPlan without consulting plans higher on the stack. Since this seems like a common error, I also modified RunThreadPlan to enforce this behavior. <rdar://problem/22543166> llvm-svn: 250084
2015-10-13 03:11:03 +08:00
if (return_value != eExpressionCompleted && log)
{
// Print a backtrace into the log so we can figure out where we are:
StreamString s;
s.PutCString("Thread state after unsuccessful completion: \n");
thread->GetStackFrameStatus (s,
0,
UINT32_MAX,
true,
UINT32_MAX);
log->PutCString(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
// 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
Rename eExecution*** to eExpression*** to be consistent with the result type. llvm-svn: 207945
2014-05-05 10:47:44 +08:00
bool should_unwind = (return_value == eExpressionInterrupted && options.DoesUnwindOnError())
|| (return_value == eExpressionHitBreakpoint && options.DoesIgnoreBreakpoints());
sweep up -Wformat warnings from gcc This is a purely mechanical change explicitly casting any parameters for printf style conversion. This cleans up the warnings emitted by gcc 4.8 on Linux. llvm-svn: 205607
2014-04-04 12:06:10 +08:00
Rename eExecution*** to eExpression*** to be consistent with the result type. llvm-svn: 207945
2014-05-05 10:47:44 +08:00
if (return_value == eExpressionCompleted
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
|| 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();
}
sweep up -Wformat warnings from gcc This is a purely mechanical change explicitly casting any parameters for printf style conversion. This cleans up the warnings emitted by gcc 4.8 on Linux. llvm-svn: 205607
2014-04-04 12:06:10 +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
// Now do some processing on the results of the run:
Rename eExecution*** to eExpression*** to be consistent with the result type. llvm-svn: 207945
2014-05-05 10:47:44 +08:00
if (return_value == eExpressionInterrupted || return_value == eExpressionHitBreakpoint)
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;
sweep up -Wformat warnings from gcc This is a purely mechanical change explicitly casting any parameters for printf style conversion. This cleans up the warnings emitted by gcc 4.8 on Linux. llvm-svn: 205607
2014-04-04 12:06:10 +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;
}
sweep up -Wformat warnings from gcc This is a purely mechanical change explicitly casting any parameters for printf style conversion. This cleans up the warnings emitted by gcc 4.8 on Linux. llvm-svn: 205607
2014-04-04 12:06:10 +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
}
sweep up -Wformat warnings from gcc This is a purely mechanical change explicitly casting any parameters for printf style conversion. This cleans up the warnings emitted by gcc 4.8 on Linux. llvm-svn: 205607
2014-04-04 12:06:10 +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();
sweep up -Wformat warnings from gcc This is a purely mechanical change explicitly casting any parameters for printf style conversion. This cleans up the warnings emitted by gcc 4.8 on Linux. llvm-svn: 205607
2014-04-04 12:06:10 +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;
sweep up -Wformat warnings from gcc This is a purely mechanical change explicitly casting any parameters for printf style conversion. This cleans up the warnings emitted by gcc 4.8 on Linux. llvm-svn: 205607
2014-04-04 12:06:10 +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
ts.Printf("<%u threads> ", num_threads);
sweep up -Wformat warnings from gcc This is a purely mechanical change explicitly casting any parameters for printf style conversion. This cleans up the warnings emitted by gcc 4.8 on Linux. llvm-svn: 205607
2014-04-04 12:06:10 +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();
sweep up -Wformat warnings from gcc This is a purely mechanical change explicitly casting any parameters for printf style conversion. This cleans up the warnings emitted by gcc 4.8 on Linux. llvm-svn: 205607
2014-04-04 12:06:10 +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 (!thread)
{
ts.Printf("<?> ");
continue;
}
sweep up -Wformat warnings from gcc This is a purely mechanical change explicitly casting any parameters for printf style conversion. This cleans up the warnings emitted by gcc 4.8 on Linux. llvm-svn: 205607
2014-04-04 12:06:10 +08:00
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();
sweep up -Wformat warnings from gcc This is a purely mechanical change explicitly casting any parameters for printf style conversion. This cleans up the warnings emitted by gcc 4.8 on Linux. llvm-svn: 205607
2014-04-04 12:06:10 +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 (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] ");
sweep up -Wformat warnings from gcc This is a purely mechanical change explicitly casting any parameters for printf style conversion. This cleans up the warnings emitted by gcc 4.8 on Linux. llvm-svn: 205607
2014-04-04 12:06:10 +08:00
Fix a misunderstanding of the ThreadPlan::OkayToDiscard flag in InferiorCallPOSIX. It was set to true, but all plans run by RunThreadPlan need to have this set to false so they will return control to RunThreadPlan without consulting plans higher on the stack. Since this seems like a common error, I also modified RunThreadPlan to enforce this behavior. <rdar://problem/22543166> llvm-svn: 250084
2015-10-13 03:11:03 +08:00
// Show the private stop info here, the public stop info will be from the last natural stop.
lldb::StopInfoSP stop_info_sp = thread->GetPrivateStopInfo();
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 (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
}
sweep up -Wformat warnings from gcc This is a purely mechanical change explicitly casting any parameters for printf style conversion. This cleans up the warnings emitted by gcc 4.8 on Linux. llvm-svn: 205607
2014-04-04 12:06:10 +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);
sweep up -Wformat warnings from gcc This is a purely mechanical change explicitly casting any parameters for printf style conversion. This cleans up the warnings emitted by gcc 4.8 on Linux. llvm-svn: 205607
2014-04-04 12:06:10 +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());
}
sweep up -Wformat warnings from gcc This is a purely mechanical change explicitly casting any parameters for printf style conversion. This cleans up the warnings emitted by gcc 4.8 on Linux. llvm-svn: 205607
2014-04-04 12:06:10 +08:00
Remove unnecessary checks for thread_plan_sp (we check for this at the top of the function.) llvm-svn: 191476
2013-09-27 09:13:01 +08:00
if (should_unwind)
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)
sweep up -Wformat warnings from gcc This is a purely mechanical change explicitly casting any parameters for printf style conversion. This cleans up the warnings emitted by gcc 4.8 on Linux. llvm-svn: 205607
2014-04-04 12:06:10 +08:00
log->Printf ("Process::RunThreadPlan: ExecutionInterrupted - discarding thread plans up to %p.",
static_cast<void*>(thread_plan_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
thread->DiscardThreadPlansUpToPlan (thread_plan_sp);
}
else
{
if (log)
sweep up -Wformat warnings from gcc This is a purely mechanical change explicitly casting any parameters for printf style conversion. This cleans up the warnings emitted by gcc 4.8 on Linux. llvm-svn: 205607
2014-04-04 12:06:10 +08:00
log->Printf ("Process::RunThreadPlan: ExecutionInterrupted - for plan: %p not discarding.",
static_cast<void*>(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
}
}
Rename eExecution*** to eExpression*** to be consistent with the result type. llvm-svn: 207945
2014-05-05 10:47:44 +08:00
else if (return_value == eExpressionSetupError)
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(): execution set up error.");
sweep up -Wformat warnings from gcc This is a purely mechanical change explicitly casting any parameters for printf style conversion. This cleans up the warnings emitted by gcc 4.8 on Linux. llvm-svn: 205607
2014-04-04 12:06:10 +08:00
This patch does a couple of things. It completes the job of using EvaluateExpressionOptions consistently throughout the inferior function calling mechanism in lldb begun in Greg's patch r194009. It removes a handful of alternate calls into the ClangUserExpression/ClangFunction/ThreadPlanCallFunction which were there for convenience. Using the EvaluateExpressionOptions removes the need for them. Using that it gets the --debug option from Greg's patch to work cleanly. It also adds another EvaluateExpressionOption to not trap exceptions when running expressions. You shouldn't use this option unless you KNOW your expression can't throw beyond itself. This is: <rdar://problem/15374885> At present this is only available through the SB API's or python. It fixes a bug where function calls would unset the ObjC & C++ exception breakpoints without checking whether they were set by somebody else already. llvm-svn: 194182
2013-11-07 08:11:47 +08:00
if (options.DoesUnwindOnError())
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);
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");
Rename eExecution*** to eExpression*** to be consistent with the result type. llvm-svn: 207945
2014-05-05 10:47:44 +08:00
return_value = eExpressionCompleted;
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->WasThreadPlanDiscarded (thread_plan_sp.get()))
{
if (log)
log->PutCString("Process::RunThreadPlan(): thread plan was discarded");
Rename eExecution*** to eExpression*** to be consistent with the result type. llvm-svn: 207945
2014-05-05 10:47:44 +08:00
return_value = eExpressionDiscarded;
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
}
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");
This patch does a couple of things. It completes the job of using EvaluateExpressionOptions consistently throughout the inferior function calling mechanism in lldb begun in Greg's patch r194009. It removes a handful of alternate calls into the ClangUserExpression/ClangFunction/ThreadPlanCallFunction which were there for convenience. Using the EvaluateExpressionOptions removes the need for them. Using that it gets the --debug option from Greg's patch to work cleanly. It also adds another EvaluateExpressionOption to not trap exceptions when running expressions. You shouldn't use this option unless you KNOW your expression can't throw beyond itself. This is: <rdar://problem/15374885> At present this is only available through the SB API's or python. It fixes a bug where function calls would unset the ObjC & C++ exception breakpoints without checking whether they were set by somebody else already. llvm-svn: 194182
2013-11-07 08:11:47 +08:00
if (options.DoesUnwindOnError() && 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);
}
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
}
sweep up -Wformat warnings from gcc This is a purely mechanical change explicitly casting any parameters for printf style conversion. This cleans up the warnings emitted by gcc 4.8 on Linux. llvm-svn: 205607
2014-04-04 12:06:10 +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
}
sweep up -Wformat warnings from gcc This is a purely mechanical change explicitly casting any parameters for printf style conversion. This cleans up the warnings emitted by gcc 4.8 on Linux. llvm-svn: 205607
2014-04-04 12:06:10 +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.
sweep up -Wformat warnings from gcc This is a purely mechanical change explicitly casting any parameters for printf style conversion. This cleans up the warnings emitted by gcc 4.8 on Linux. llvm-svn: 205607
2014-04-04 12:06:10 +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 (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:
Fix lock hierarchy violation in Process (lock ordering of ThreadList mutex and StackFrameList mutex) - this fix ensures the ThreadList mutex is always locked before the StackFrameList mutex Situation where deadlock could occur (without this fix): Thread 1 is in Process::WillResume and locks the ThreadList mutex (on entry), and subsequently calls StackFrameList::Clear() which locks the StackFrameList mutex. Meanwhile, thread 2 is in Process::RunThreadPlan and calls Thread::SetSelectedFrame() (which locks the StackFrameList mutex) before calling GetSelectedThread (which attempts to lock the ThreadList mutex) In my testing on both Linux and Mac OS X, I was unable to reproduce any hangs with this patch applied. llvm-svn: 187522
2013-08-01 04:21:20 +08:00
Mutex::Locker lock(GetThreadList().GetMutex());
Roll back the changes I made in r193907 which created a new Frame pure virtual base class and made StackFrame a subclass of that. As I started to build on top of that arrangement today, I found that it wasn't working out like I intended. Instead I'll try sticking with the single StackFrame class -- there's too much code duplication to make a more complicated class hierarchy sensible I think. llvm-svn: 193983
2013-11-04 17:33:30 +08:00
StackFrameSP old_frame_sp = GetThreadList().GetSelectedThread()->GetFrameWithStackID(selected_stack_id);
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 (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
}
}
}
sweep up -Wformat warnings from gcc This is a purely mechanical change explicitly casting any parameters for printf style conversion. This cleans up the warnings emitted by gcc 4.8 on Linux. llvm-svn: 205607
2014-04-04 12:06:10 +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.
sweep up -Wformat warnings from gcc This is a purely mechanical change explicitly casting any parameters for printf style conversion. This cleans up the warnings emitted by gcc 4.8 on Linux. llvm-svn: 205607
2014-04-04 12:06:10 +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
}
sweep up -Wformat warnings from gcc This is a purely mechanical change explicitly casting any parameters for printf style conversion. This cleans up the warnings emitted by gcc 4.8 on Linux. llvm-svn: 205607
2014-04-04 12:06:10 +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
return return_value;
}
const char *
Make the Expression Execution result enum available to the SB API layer. Add a callback that will allow an expression to be cancelled between the expression evaluation stages (for the ClangUserExpressions.) <rdar://problem/16790467>, <rdar://problem/16573440> llvm-svn: 207944
2014-05-05 10:26:40 +08:00
Process::ExecutionResultAsCString (ExpressionResults result)
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
{
const char *result_name;
switch (result)
{
Rename eExecution*** to eExpression*** to be consistent with the result type. llvm-svn: 207945
2014-05-05 10:47:44 +08:00
case eExpressionCompleted:
result_name = "eExpressionCompleted";
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
break;
Rename eExecution*** to eExpression*** to be consistent with the result type. llvm-svn: 207945
2014-05-05 10:47:44 +08:00
case eExpressionDiscarded:
result_name = "eExpressionDiscarded";
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
break;
Rename eExecution*** to eExpression*** to be consistent with the result type. llvm-svn: 207945
2014-05-05 10:47:44 +08:00
case eExpressionInterrupted:
result_name = "eExpressionInterrupted";
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
break;
Rename eExecution*** to eExpression*** to be consistent with the result type. llvm-svn: 207945
2014-05-05 10:47:44 +08:00
case eExpressionHitBreakpoint:
result_name = "eExpressionHitBreakpoint";
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
break;
Rename eExecution*** to eExpression*** to be consistent with the result type. llvm-svn: 207945
2014-05-05 10:47:44 +08:00
case eExpressionSetupError:
result_name = "eExpressionSetupError";
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
break;
Rename eExecution*** to eExpression*** to be consistent with the result type. llvm-svn: 207945
2014-05-05 10:47:44 +08:00
case eExpressionParseError:
result_name = "eExpressionParseError";
Make the Expression Execution result enum available to the SB API layer. Add a callback that will allow an expression to be cancelled between the expression evaluation stages (for the ClangUserExpressions.) <rdar://problem/16790467>, <rdar://problem/16573440> llvm-svn: 207944
2014-05-05 10:26:40 +08:00
break;
Rename eExecution*** to eExpression*** to be consistent with the result type. llvm-svn: 207945
2014-05-05 10:47:44 +08:00
case eExpressionResultUnavailable:
result_name = "eExpressionResultUnavailable";
Make the Expression Execution result enum available to the SB API layer. Add a callback that will allow an expression to be cancelled between the expression evaluation stages (for the ClangUserExpressions.) <rdar://problem/16790467>, <rdar://problem/16573440> llvm-svn: 207944
2014-05-05 10:26:40 +08:00
break;
Rename eExecution*** to eExpression*** to be consistent with the result type. llvm-svn: 207945
2014-05-05 10:47:44 +08:00
case eExpressionTimedOut:
result_name = "eExpressionTimedOut";
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
break;
Rename eExecution*** to eExpression*** to be consistent with the result type. llvm-svn: 207945
2014-05-05 10:47:44 +08:00
case eExpressionStoppedForDebug:
result_name = "eExpressionStoppedForDebug";
This patch does a couple of things. It completes the job of using EvaluateExpressionOptions consistently throughout the inferior function calling mechanism in lldb begun in Greg's patch r194009. It removes a handful of alternate calls into the ClangUserExpression/ClangFunction/ThreadPlanCallFunction which were there for convenience. Using the EvaluateExpressionOptions removes the need for them. Using that it gets the --debug option from Greg's patch to work cleanly. It also adds another EvaluateExpressionOption to not trap exceptions when running expressions. You shouldn't use this option unless you KNOW your expression can't throw beyond itself. This is: <rdar://problem/15374885> At present this is only available through the SB API's or python. It fixes a bug where function calls would unset the ObjC & C++ exception breakpoints without checking whether they were set by somebody else already. llvm-svn: 194182
2013-11-07 08:11:47 +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
}
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;
Don't hold the ThreadList lock over calls to the GetStatus (Process or Thread) calls or the lower levels of the Process won't be able to restart. <rdar://problem/16244835> llvm-svn: 203233
2014-03-07 19:20:03 +08:00
// You can't hold the thread list lock while calling Thread::GetStatus. That very well might run code (e.g. if we need it
// to get return values or arguments.) For that to work the process has to be able to acquire it. So instead copy the thread
// ID's, and look them up one by one:
uint32_t num_threads;
Fixed an issue where if the operating system python plug-in is changed at runtime, it wouldn't cause the process to reload the new operating system plug-in, now it does. This is currently controlled by a setting: (lldb) settings set target.process.python-os-plugin-path <path> Or clearing it with: (lldb) settings clear target.process.python-os-plugin-path The process will now reload the OperatingSystem plug-in. This was implemented by: - adding the ability to set a notify callback for when an option value is changed - added the ability for the process plug-in to load the operating system plug-in on the fly - fixed bugs in the Process::GetStatus() so all threads are displayed if their thread IDs are larger than 32 bits - adding a callback in ProcessProperties to tell when the "python-os-plugin-path" is changed by the user - fixing a crasher in ProcessMachCore that happens when updating the thread list when the OS plugin is reloaded llvm-svn: 225831
2015-01-14 05:13:08 +08:00
std::vector<lldb::tid_t> thread_id_array;
Don't hold the ThreadList lock over calls to the GetStatus (Process or Thread) calls or the lower levels of the Process won't be able to restart. <rdar://problem/16244835> llvm-svn: 203233
2014-03-07 19:20:03 +08:00
//Scope for thread list locker;
{
Mutex::Locker locker (GetThreadList().GetMutex());
ThreadList &curr_thread_list = GetThreadList();
num_threads = curr_thread_list.GetSize();
uint32_t idx;
Fixed an issue where if the operating system python plug-in is changed at runtime, it wouldn't cause the process to reload the new operating system plug-in, now it does. This is currently controlled by a setting: (lldb) settings set target.process.python-os-plugin-path <path> Or clearing it with: (lldb) settings clear target.process.python-os-plugin-path The process will now reload the OperatingSystem plug-in. This was implemented by: - adding the ability to set a notify callback for when an option value is changed - added the ability for the process plug-in to load the operating system plug-in on the fly - fixed bugs in the Process::GetStatus() so all threads are displayed if their thread IDs are larger than 32 bits - adding a callback in ProcessProperties to tell when the "python-os-plugin-path" is changed by the user - fixing a crasher in ProcessMachCore that happens when updating the thread list when the OS plugin is reloaded llvm-svn: 225831
2015-01-14 05:13:08 +08:00
thread_id_array.resize(num_threads);
Don't hold the ThreadList lock over calls to the GetStatus (Process or Thread) calls or the lower levels of the Process won't be able to restart. <rdar://problem/16244835> llvm-svn: 203233
2014-03-07 19:20:03 +08:00
for (idx = 0; idx < num_threads; ++idx)
Fixed an issue where if the operating system python plug-in is changed at runtime, it wouldn't cause the process to reload the new operating system plug-in, now it does. This is currently controlled by a setting: (lldb) settings set target.process.python-os-plugin-path <path> Or clearing it with: (lldb) settings clear target.process.python-os-plugin-path The process will now reload the OperatingSystem plug-in. This was implemented by: - adding the ability to set a notify callback for when an option value is changed - added the ability for the process plug-in to load the operating system plug-in on the fly - fixed bugs in the Process::GetStatus() so all threads are displayed if their thread IDs are larger than 32 bits - adding a callback in ProcessProperties to tell when the "python-os-plugin-path" is changed by the user - fixing a crasher in ProcessMachCore that happens when updating the thread list when the OS plugin is reloaded llvm-svn: 225831
2015-01-14 05:13:08 +08:00
thread_id_array[idx] = curr_thread_list.GetThreadAtIndex(idx)->GetID();
Don't hold the ThreadList lock over calls to the GetStatus (Process or Thread) calls or the lower levels of the Process won't be able to restart. <rdar://problem/16244835> llvm-svn: 203233
2014-03-07 19:20:03 +08:00
}
Centralized a lot of the status information for processes, threads, and stack frame down in the lldb_private::Process, lldb_private::Thread, lldb_private::StackFrameList and the lldb_private::StackFrame classes. We had some command line commands that had duplicate versions of the process status output ("thread list" and "process status" for example). Removed the "file" command and placed it where it should have been: "target create". Made an alias for "file" to "target create" so we stay compatible with GDB commands. We can now have multple usable targets in lldb at the same time. This is nice for comparing two runs of a program or debugging more than one binary at the same time. The new command is "target select <target-idx>" and also to see a list of the current targets you can use the new "target list" command. The flow in a debug session can be: (lldb) target create /path/to/exe/a.out (lldb) breakpoint set --name main (lldb) run ... hit breakpoint (lldb) target create /bin/ls (lldb) run /tmp Process 36001 exited with status = 0 (0x00000000) (lldb) target list Current targets: target #0: /tmp/args/a.out ( arch=x86_64-apple-darwin, platform=localhost, pid=35999, state=stopped ) * target #1: /bin/ls ( arch=x86_64-apple-darwin, platform=localhost, pid=36001, state=exited ) (lldb) target select 0 Current targets: * target #0: /tmp/args/a.out ( arch=x86_64-apple-darwin, platform=localhost, pid=35999, state=stopped ) target #1: /bin/ls ( arch=x86_64-apple-darwin, platform=localhost, pid=36001, state=exited ) (lldb) bt * thread #1: tid = 0x2d03, 0x0000000100000b9a a.out`main + 42 at main.c:16, stop reason = breakpoint 1.1 frame #0: 0x0000000100000b9a a.out`main + 42 at main.c:16 frame #1: 0x0000000100000b64 a.out`start + 52 Above we created a target for "a.out" and ran and hit a breakpoint at "main". Then we created a new target for /bin/ls and ran it. Then we listed the targest and selected our original "a.out" program, so we showed two concurent debug sessions going on at the same time. llvm-svn: 129695
2011-04-18 16:33:37 +08:00
for (uint32_t i = 0; i < num_threads; i++)
{
Fixed an issue where if the operating system python plug-in is changed at runtime, it wouldn't cause the process to reload the new operating system plug-in, now it does. This is currently controlled by a setting: (lldb) settings set target.process.python-os-plugin-path <path> Or clearing it with: (lldb) settings clear target.process.python-os-plugin-path The process will now reload the OperatingSystem plug-in. This was implemented by: - adding the ability to set a notify callback for when an option value is changed - added the ability for the process plug-in to load the operating system plug-in on the fly - fixed bugs in the Process::GetStatus() so all threads are displayed if their thread IDs are larger than 32 bits - adding a callback in ProcessProperties to tell when the "python-os-plugin-path" is changed by the user - fixing a crasher in ProcessMachCore that happens when updating the thread list when the OS plugin is reloaded llvm-svn: 225831
2015-01-14 05:13:08 +08:00
ThreadSP thread_sp(GetThreadList().FindThreadByID(thread_id_array[i]));
Don't hold the ThreadList lock over calls to the GetStatus (Process or Thread) calls or the lower levels of the Process won't be able to restart. <rdar://problem/16244835> llvm-svn: 203233
2014-03-07 19:20:03 +08:00
if (thread_sp)
Centralized a lot of the status information for processes, threads, and stack frame down in the lldb_private::Process, lldb_private::Thread, lldb_private::StackFrameList and the lldb_private::StackFrame classes. We had some command line commands that had duplicate versions of the process status output ("thread list" and "process status" for example). Removed the "file" command and placed it where it should have been: "target create". Made an alias for "file" to "target create" so we stay compatible with GDB commands. We can now have multple usable targets in lldb at the same time. This is nice for comparing two runs of a program or debugging more than one binary at the same time. The new command is "target select <target-idx>" and also to see a list of the current targets you can use the new "target list" command. The flow in a debug session can be: (lldb) target create /path/to/exe/a.out (lldb) breakpoint set --name main (lldb) run ... hit breakpoint (lldb) target create /bin/ls (lldb) run /tmp Process 36001 exited with status = 0 (0x00000000) (lldb) target list Current targets: target #0: /tmp/args/a.out ( arch=x86_64-apple-darwin, platform=localhost, pid=35999, state=stopped ) * target #1: /bin/ls ( arch=x86_64-apple-darwin, platform=localhost, pid=36001, state=exited ) (lldb) target select 0 Current targets: * target #0: /tmp/args/a.out ( arch=x86_64-apple-darwin, platform=localhost, pid=35999, state=stopped ) target #1: /bin/ls ( arch=x86_64-apple-darwin, platform=localhost, pid=36001, state=exited ) (lldb) bt * thread #1: tid = 0x2d03, 0x0000000100000b9a a.out`main + 42 at main.c:16, stop reason = breakpoint 1.1 frame #0: 0x0000000100000b9a a.out`main + 42 at main.c:16 frame #1: 0x0000000100000b64 a.out`start + 52 Above we created a target for "a.out" and ran and hit a breakpoint at "main". Then we created a new target for /bin/ls and ran it. Then we listed the targest and selected our original "a.out" program, so we showed two concurent debug sessions going on at the same time. llvm-svn: 129695
2011-04-18 16:33:37 +08:00
{
if (only_threads_with_stop_reason)
{
Don't hold the ThreadList lock over calls to the GetStatus (Process or Thread) calls or the lower levels of the Process won't be able to restart. <rdar://problem/16244835> llvm-svn: 203233
2014-03-07 19:20:03 +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.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;
}
Don't hold the ThreadList lock over calls to the GetStatus (Process or Thread) calls or the lower levels of the Process won't be able to restart. <rdar://problem/16244835> llvm-svn: 203233
2014-03-07 19:20:03 +08:00
thread_sp->GetStatus (strm,
Centralized a lot of the status information for processes, threads, and stack frame down in the lldb_private::Process, lldb_private::Thread, lldb_private::StackFrameList and the lldb_private::StackFrame classes. We had some command line commands that had duplicate versions of the process status output ("thread list" and "process status" for example). Removed the "file" command and placed it where it should have been: "target create". Made an alias for "file" to "target create" so we stay compatible with GDB commands. We can now have multple usable targets in lldb at the same time. This is nice for comparing two runs of a program or debugging more than one binary at the same time. The new command is "target select <target-idx>" and also to see a list of the current targets you can use the new "target list" command. The flow in a debug session can be: (lldb) target create /path/to/exe/a.out (lldb) breakpoint set --name main (lldb) run ... hit breakpoint (lldb) target create /bin/ls (lldb) run /tmp Process 36001 exited with status = 0 (0x00000000) (lldb) target list Current targets: target #0: /tmp/args/a.out ( arch=x86_64-apple-darwin, platform=localhost, pid=35999, state=stopped ) * target #1: /bin/ls ( arch=x86_64-apple-darwin, platform=localhost, pid=36001, state=exited ) (lldb) target select 0 Current targets: * target #0: /tmp/args/a.out ( arch=x86_64-apple-darwin, platform=localhost, pid=35999, state=stopped ) target #1: /bin/ls ( arch=x86_64-apple-darwin, platform=localhost, pid=36001, state=exited ) (lldb) bt * thread #1: tid = 0x2d03, 0x0000000100000b9a a.out`main + 42 at main.c:16, stop reason = breakpoint 1.1 frame #0: 0x0000000100000b9a a.out`main + 42 at main.c:16 frame #1: 0x0000000100000b64 a.out`start + 52 Above we created a target for "a.out" and ran and hit a breakpoint at "main". Then we created a new target for /bin/ls and ran it. Then we listed the targest and selected our original "a.out" program, so we showed two concurent debug sessions going on at the same time. llvm-svn: 129695
2011-04-18 16:33:37 +08:00
start_frame,
num_frames,
num_frames_with_source);
++num_thread_infos_dumped;
}
Don't hold the ThreadList lock over calls to the GetStatus (Process or Thread) calls or the lower levels of the Process won't be able to restart. <rdar://problem/16244835> llvm-svn: 203233
2014-03-07 19:20:03 +08:00
else
{
Log *log(lldb_private::GetLogIfAnyCategoriesSet (LIBLLDB_LOG_PROCESS));
if (log)
log->Printf("Process::GetThreadStatus - thread 0x" PRIu64 " vanished while running Thread::GetStatus.");
}
Centralized a lot of the status information for processes, threads, and stack frame down in the lldb_private::Process, lldb_private::Thread, lldb_private::StackFrameList and the lldb_private::StackFrame classes. We had some command line commands that had duplicate versions of the process status output ("thread list" and "process status" for example). Removed the "file" command and placed it where it should have been: "target create". Made an alias for "file" to "target create" so we stay compatible with GDB commands. We can now have multple usable targets in lldb at the same time. This is nice for comparing two runs of a program or debugging more than one binary at the same time. The new command is "target select <target-idx>" and also to see a list of the current targets you can use the new "target list" command. The flow in a debug session can be: (lldb) target create /path/to/exe/a.out (lldb) breakpoint set --name main (lldb) run ... hit breakpoint (lldb) target create /bin/ls (lldb) run /tmp Process 36001 exited with status = 0 (0x00000000) (lldb) target list Current targets: target #0: /tmp/args/a.out ( arch=x86_64-apple-darwin, platform=localhost, pid=35999, state=stopped ) * target #1: /bin/ls ( arch=x86_64-apple-darwin, platform=localhost, pid=36001, state=exited ) (lldb) target select 0 Current targets: * target #0: /tmp/args/a.out ( arch=x86_64-apple-darwin, platform=localhost, pid=35999, state=stopped ) target #1: /bin/ls ( arch=x86_64-apple-darwin, platform=localhost, pid=36001, state=exited ) (lldb) bt * thread #1: tid = 0x2d03, 0x0000000100000b9a a.out`main + 42 at main.c:16, stop reason = breakpoint 1.1 frame #0: 0x0000000100000b9a a.out`main + 42 at main.c:16 frame #1: 0x0000000100000b64 a.out`start + 52 Above we created a target for "a.out" and ran and hit a breakpoint at "main". Then we created a new target for /bin/ls and ran it. Then we listed the targest and selected our original "a.out" program, so we showed two concurent debug sessions going on at the same time. llvm-svn: 129695
2011-04-18 16:33:37 +08:00
}
return num_thread_infos_dumped;
}
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);
Small tweaks to make the editline sources match the lldb source layout. llvm-svn: 222171
2014-11-18 04:10:15 +08:00
if (result == true)
result = this_result;
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
}
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
Further reduce the header footprint of Process.h No functional change here, only deletes unnecessary headers and moves one function's body from the .h file to the .cpp. llvm-svn: 231145
2015-03-04 05:51:25 +08:00
ProcessRunLock &
Process::GetRunLock()
{
if (m_private_state_thread.EqualsThread(Host::GetCurrentThread()))
return m_private_run_lock;
else
return m_public_run_lock;
}
<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();
Add new Queue, QueueItem, Queuelist, SBQueue, SBQueueItem classes to represent libdispatch aka Grand Central Dispatch (GCD) queues. Still fleshing out the documentation and testing of these but the overall API is settling down so it's a good time to check it in. <rdar://problem/15600370> llvm-svn: 197190
2013-12-13 08:29:16 +08:00
m_extended_thread_list.Flush();
m_extended_thread_stop_id = 0;
m_queue_list.Clear();
m_queue_list_stop_id = 0;
<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
}
<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 ()
{
Add some logging around Process attaching and inferior exec handling. llvm-svn: 216630
2014-08-28 06:58:26 +08:00
Log *log(lldb_private::GetLogIfAllCategoriesSet (LIBLLDB_LOG_PROCESS));
if (log)
log->Printf ("Process::%s()", __FUNCTION__);
<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
Target &target = GetTarget();
target.CleanupProcess ();
Fixed the the breakpoint test case failures. There were 6 on darwin. All of these were related to the recent changes for exec. llvm-svn: 194298
2013-11-09 08:03:31 +08:00
target.ClearModules(false);
<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
m_dynamic_checkers_ap.reset();
m_abi_sp.reset();
Add a new system runtime plugin type - just the top level class, not any actual plugin implementation yet. <rdar://problem/15314068> llvm-svn: 194044
2013-11-05 11:57:19 +08:00
m_system_runtime_ap.reset();
<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
m_os_ap.reset();
<rdar://problem/13892516> LLDB can now debug across calls to exec when the architecture changes from say i386 to x86_64 (on darwin). llvm-svn: 182345
2013-05-21 09:00:52 +08:00
m_dyld_ap.reset();
Add support for JIT debugging on Linux using the GDB JIT interface. Patch written with Keno Fischer. llvm-svn: 202956
2014-03-05 18:12:43 +08:00
m_jit_loaders_ap.reset();
<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
m_image_tokens.clear();
m_allocated_memory_cache.Clear();
m_language_runtimes.clear();
LLDB AddressSanitizer instrumentation runtime plugin, breakpint on error and report data extraction Reviewed at http://reviews.llvm.org/D5592 This patch gives LLDB some ability to interact with AddressSanitizer runtime library, on top of what we already have (historical memory stack traces provided by ASan). Namely, that's the ability to stop on an error caught by ASan, and access the report information that are associated with it. The report information is also exposed into SB API. More precisely this patch... adds a new plugin type, InstrumentationRuntime, which should serve as a generic superclass for other instrumentation runtime libraries, these plugins get notified when modules are loaded, so they get a chance to "activate" when a specific dynamic library is loaded an instance of this plugin type, AddressSanitizerRuntime, which activates itself when it sees the ASan dynamic library or founds ASan statically linked in the executable adds a collection of these plugins into the Process class AddressSanitizerRuntime sets an internal breakpoint on __asan::AsanDie(), and when this breakpoint gets hit, it retrieves the report information from ASan this breakpoint is then exposed as a new StopReason, eStopReasonInstrumentation, with a new StopInfo subclass, InstrumentationRuntimeStopInfo the StopInfo superclass is extended with a m_extended_info field (it's a StructuredData::ObjectSP), that can hold arbitrary JSON-like data, which is the way the new plugin provides the report data the "thread info" command now accepts a "-s" flag that prints out the JSON data of a stop reason (same way the "-j" flag works now) SBThread has a new API, GetStopReasonExtendedInfoAsJSON, which dumps the JSON string into a SBStream adds a test case for all of this I plan to also get rid of the original ASan plugin (memory history stack traces) and use an instance of AddressSanitizerRuntime for that purpose. Kuba llvm-svn: 219546
2014-10-11 07:43:03 +08:00
m_instrumentation_runtimes.clear();
<rdar://problem/13892516> LLDB can now debug across calls to exec when the architecture changes from say i386 to x86_64 (on darwin). llvm-svn: 182345
2013-05-21 09:00:52 +08:00
m_thread_list.DiscardThreadPlans();
m_memory_cache.Clear(true);
Handle thumb IT instructions correctly all the time. The issue with Thumb IT (if/then) instructions is the IT instruction preceeds up to four instructions that are made conditional. If a breakpoint is placed on one of the conditional instructions, the instruction either needs to match the thumb opcode size (2 or 4 bytes) or a BKPT instruction needs to be used as these are always unconditional (even in a IT instruction). If BKPT instructions are used, then we might end up stopping on an instruction that won't get executed. So if we do stop at a BKPT instruction, we need to continue if the condition is not true. When using the BKPT isntructions are easy in that you don't need to detect the size of the breakpoint that needs to be used when setting a breakpoint even in a thumb IT instruction. The bad part is you will now always stop at the opcode location and let LLDB determine if it should auto-continue. If the BKPT instruction is used, the BKPT that is used for ARM code should be something that also triggers the BKPT instruction in Thumb in case you set a breakpoint in the middle of code and the code is actually Thumb code. A value of 0xE120BE70 will work since the lower 16 bits being 0xBE70 happens to be a Thumb BKPT instruction. The alternative is to use trap or illegal instructions that the kernel will translate into breakpoint hits. On Mac this was 0xE7FFDEFE for ARM and 0xDEFE for Thumb. The darwin kernel currently doesn't recognize any 32 bit Thumb instruction as a instruction that will get turned into a breakpoint exception (EXC_BREAKPOINT), so we had to use the BKPT instruction on Mac. The linux kernel recognizes a 16 and a 32 bit instruction as valid thumb breakpoint opcodes. The benefit of using 16 or 32 bit instructions is you don't stop on opcodes in a IT block when the condition doesn't match. To further complicate things, single stepping on ARM is often implemented by modifying the BCR/BVR registers and setting the processor to stop when the PC is not equal to the current value. This means single stepping is another way the ARM target can stop on instructions that won't get executed. This patch does the following: 1 - Fix the internal debugserver for Apple to use the BKPT instruction for ARM and Thumb 2 - Fix LLDB to catch when we stop in the middle of a Thumb IT instruction and continue if we stop at an instruction that won't execute 3 - Fixes this in a way that will work for any target on any platform as long as it is ARM/Thumb 4 - Adds a patch for ignoring conditions that don't match when in ARM mode (see below) This patch also provides the code that implements the same thing for ARM instructions, though it is disabled for now. The ARM patch will check the condition of the instruction in ARM mode and continue if the condition isn't true (and therefore the instruction would not be executed). Again, this is not enable, but the code for it has been added. <rdar://problem/19145455> llvm-svn: 223851
2014-12-10 07:31:02 +08:00
m_stop_info_override_callback = NULL;
<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
DoDidExec();
CompleteAttach ();
<rdar://problem/15367122> Fixed the test case for "test/functionalities/exec/TestExec.py" on Darwin. The issue was breakpoints were persisting and causing problems. When we exec, we need to clear out the process and target and start fresh with nothing and let the breakpoints populate themselves again. This patch correctly clears out the breakpoints and also flushes the process so that the objects (process/thread/frame) give out valid information. llvm-svn: 194106
2013-11-06 07:28:00 +08:00
// Flush the process (threads and all stack frames) after running CompleteAttach()
// in case the dynamic loader loaded things in new locations.
Flush();
Fixed the the breakpoint test case failures. There were 6 on darwin. All of these were related to the recent changes for exec. llvm-svn: 194298
2013-11-09 08:03:31 +08:00
// After we figure out what was loaded/unloaded in CompleteAttach,
// we need to let the target know so it can do any cleanup it needs to.
target.DidExec();
<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
}
<rdar://problem/15367122> Fixed the test case for "test/functionalities/exec/TestExec.py" on Darwin. The issue was breakpoints were persisting and causing problems. When we exec, we need to clear out the process and target and start fresh with nothing and let the breakpoints populate themselves again. This patch correctly clears out the breakpoints and also flushes the process so that the objects (process/thread/frame) give out valid information. llvm-svn: 194106
2013-11-06 07:28:00 +08:00
Get the breakpoint setting, and the Mac OS X DYLD trampolines and expression evaluator to handle Indirect symbols correctly. There were a couple of pieces to this. 1) When a breakpoint location finds itself pointing to an Indirect symbol, when the site for it is created it needs to resolve the symbol and actually set the site at its target. 2) Not all breakpoints want to do this (i.e. a straight address breakpoint should always set itself on the specified address, so somem machinery was needed to specify that. 3) I added some info to the break list output for indirect symbols so you could see what was happening. Also I made it clear when we re-route through re-exported symbols. 4) I moved ResolveIndirectFunction from ProcessPosix to Process since it works the exact same way on Mac OS X and the other posix systems. If we find a platform that doesn't do it this way, they can override the call in Process. 5) Fixed one bug in RunThreadPlan, if you were trying to run a thread plan after a "running" event had been broadcast, the event coalescing would cause you to miss the ThreadPlan running event. So I added a way to override the coalescing. 6) Made DynamicLoaderMacOSXDYLD::GetStepThroughTrampolinePlan handle Indirect & Re-exported symbols. <rdar://problem/15280639> llvm-svn: 198976
2014-01-11 07:46:59 +08:00
addr_t
Process::ResolveIndirectFunction(const Address *address, Error &error)
{
if (address == nullptr)
{
Fix null dereference if address is NULL. llvm-svn: 201026
2014-02-09 04:22:05 +08:00
error.SetErrorString("Invalid address argument");
Get the breakpoint setting, and the Mac OS X DYLD trampolines and expression evaluator to handle Indirect symbols correctly. There were a couple of pieces to this. 1) When a breakpoint location finds itself pointing to an Indirect symbol, when the site for it is created it needs to resolve the symbol and actually set the site at its target. 2) Not all breakpoints want to do this (i.e. a straight address breakpoint should always set itself on the specified address, so somem machinery was needed to specify that. 3) I added some info to the break list output for indirect symbols so you could see what was happening. Also I made it clear when we re-route through re-exported symbols. 4) I moved ResolveIndirectFunction from ProcessPosix to Process since it works the exact same way on Mac OS X and the other posix systems. If we find a platform that doesn't do it this way, they can override the call in Process. 5) Fixed one bug in RunThreadPlan, if you were trying to run a thread plan after a "running" event had been broadcast, the event coalescing would cause you to miss the ThreadPlan running event. So I added a way to override the coalescing. 6) Made DynamicLoaderMacOSXDYLD::GetStepThroughTrampolinePlan handle Indirect & Re-exported symbols. <rdar://problem/15280639> llvm-svn: 198976
2014-01-11 07:46:59 +08:00
return LLDB_INVALID_ADDRESS;
}
addr_t function_addr = LLDB_INVALID_ADDRESS;
addr_t addr = address->GetLoadAddress(&GetTarget());
std::map<addr_t,addr_t>::const_iterator iter = m_resolved_indirect_addresses.find(addr);
if (iter != m_resolved_indirect_addresses.end())
{
function_addr = (*iter).second;
}
else
{
if (!InferiorCall(this, address, function_addr))
{
Symbol *symbol = address->CalculateSymbolContextSymbol();
error.SetErrorStringWithFormat ("Unable to call resolver for indirect function %s",
symbol ? symbol->GetName().AsCString() : "<UNKNOWN>");
function_addr = LLDB_INVALID_ADDRESS;
}
else
{
m_resolved_indirect_addresses.insert(std::pair<addr_t, addr_t>(addr, function_addr));
}
}
return function_addr;
}
Create a Process::ModulesDidLoad() method to handle process-related tasks, as suggested by Jim Ingham. Make JITLoader instances use this to probe only new modules for relevant JIT symbols. Also re-enable the JITLoader hooks in Process. llvm-svn: 203774
2014-03-13 17:37:02 +08:00
void
Process::ModulesDidLoad (ModuleList &module_list)
{
LLDB AddressSanitizer instrumentation runtime plugin, breakpint on error and report data extraction Reviewed at http://reviews.llvm.org/D5592 This patch gives LLDB some ability to interact with AddressSanitizer runtime library, on top of what we already have (historical memory stack traces provided by ASan). Namely, that's the ability to stop on an error caught by ASan, and access the report information that are associated with it. The report information is also exposed into SB API. More precisely this patch... adds a new plugin type, InstrumentationRuntime, which should serve as a generic superclass for other instrumentation runtime libraries, these plugins get notified when modules are loaded, so they get a chance to "activate" when a specific dynamic library is loaded an instance of this plugin type, AddressSanitizerRuntime, which activates itself when it sees the ASan dynamic library or founds ASan statically linked in the executable adds a collection of these plugins into the Process class AddressSanitizerRuntime sets an internal breakpoint on __asan::AsanDie(), and when this breakpoint gets hit, it retrieves the report information from ASan this breakpoint is then exposed as a new StopReason, eStopReasonInstrumentation, with a new StopInfo subclass, InstrumentationRuntimeStopInfo the StopInfo superclass is extended with a m_extended_info field (it's a StructuredData::ObjectSP), that can hold arbitrary JSON-like data, which is the way the new plugin provides the report data the "thread info" command now accepts a "-s" flag that prints out the JSON data of a stop reason (same way the "-j" flag works now) SBThread has a new API, GetStopReasonExtendedInfoAsJSON, which dumps the JSON string into a SBStream adds a test case for all of this I plan to also get rid of the original ASan plugin (memory history stack traces) and use an instance of AddressSanitizerRuntime for that purpose. Kuba llvm-svn: 219546
2014-10-11 07:43:03 +08:00
SystemRuntime *sys_runtime = GetSystemRuntime();
if (sys_runtime)
{
sys_runtime->ModulesDidLoad (module_list);
}
GetJITLoaders().ModulesDidLoad (module_list);
// Give runtimes a chance to be created.
InstrumentationRuntime::ModulesDidLoad(module_list, this, m_instrumentation_runtimes);
// Tell runtimes about new modules.
for (auto pos = m_instrumentation_runtimes.begin(); pos != m_instrumentation_runtimes.end(); ++pos)
{
InstrumentationRuntimeSP runtime = pos->second;
runtime->ModulesDidLoad(module_list);
}
Create a Process::ModulesDidLoad() method to handle process-related tasks, as suggested by Jim Ingham. Make JITLoader instances use this to probe only new modules for relevant JIT symbols. Also re-enable the JITLoader hooks in Process. llvm-svn: 203774
2014-03-13 17:37:02 +08:00
Add new virtual method for language runtime plug-ins: virtual void LanguageRuntime::ModulesDidLoad (const ModuleList &module_list); Then reorganized how the objective C plug-in is notified so it will work for all LanguageRuntime subclasses. llvm-svn: 235118
2015-04-17 01:13:34 +08:00
// Let any language runtimes we have already created know
// about the modules that loaded.
// Iterate over a copy of this language runtime list in case
// the language runtime ModulesDidLoad somehow causes the language
// riuntime to be unloaded.
LanguageRuntimeCollection language_runtimes(m_language_runtimes);
for (const auto &pair: language_runtimes)
{
// We must check language_runtime_sp to make sure it is not
// NULL as we might cache the fact that we didn't have a
// language runtime for a language.
LanguageRuntimeSP language_runtime_sp = pair.second;
if (language_runtime_sp)
language_runtime_sp->ModulesDidLoad(module_list);
}
Add an OperatingSystem plugin to support goroutines The Go runtime schedules user level threads (goroutines) across real threads. This adds an OS plugin to create memory threads for goroutines. It supports the 1.4 and 1.5 go runtime. Differential Revision: http://reviews.llvm.org/D5871 llvm-svn: 247852
2015-09-17 05:20:44 +08:00
LoadOperatingSystemPlugin(false);
Create a Process::ModulesDidLoad() method to handle process-related tasks, as suggested by Jim Ingham. Make JITLoader instances use this to probe only new modules for relevant JIT symbols. Also re-enable the JITLoader hooks in Process. llvm-svn: 203774
2014-03-13 17:37:02 +08:00
}
Implement ASan history threads in SB API Reviewed at http://reviews.llvm.org/D5219 and http://lists.cs.uiuc.edu/pipermail/lldb-commits/Week-of-Mon-20140901/012809.html llvm-svn: 217300
2014-09-06 09:33:13 +08:00
Second part of indicating when the user is stopped in optimized code. The first part was in r243508 -- the extent of the UI changes in that patchset was to add "[opt]" to the frame-format when a stack frame was built with optimized code. In this change, when a stack frame built with optimization is selected, a message will be printed to the async output channel -- opt1.c was compiled with optimization - stepping may behave oddly; variables may not be available. The warning will be only be printed once per source file in a debug session. These warnings may be disabled by settings set target.process.optimization-warnings false Internally, a new Process::PrintWarning() method has been added for warnings that we want to print only once to the user. It takes a type of warning (currently only eWarningsOptimization) and an object pointer (CompileUnit*) - the warning will only be printed once for a given object pointer value. This is a bit of a prototype of this change - I think we will be tweaking it more in the future. But I wanted to land this and see how it goes. Advanced users will find these warnings unnecessary noise and will quickly disable them - but anyone who maintains a debugger knows that debugging optimized code, without realizing it, is a constant source of confusion and frustation for more typical debugger users. I imagine there will be more of these "warn once per whatever" style warnings that we will want to add in the future and we'll need to come up with a better way for enabling/disabling them. But I'm not srue what form that warning settings should take and I didn't want to code up something that we regret later, so for now I just added another process setting for this one warning. <rdar://problem/19281172> llvm-svn: 244190
2015-08-06 11:27:10 +08:00
void
When printing warnings, the repeat_key should be const void * because the data is never accessed, the pointer is the only useful piece of data. llvm-svn: 255090
2015-12-09 09:25:01 +08:00
Process::PrintWarning (uint64_t warning_type, const void *repeat_key, const char *fmt, ...)
Second part of indicating when the user is stopped in optimized code. The first part was in r243508 -- the extent of the UI changes in that patchset was to add "[opt]" to the frame-format when a stack frame was built with optimized code. In this change, when a stack frame built with optimization is selected, a message will be printed to the async output channel -- opt1.c was compiled with optimization - stepping may behave oddly; variables may not be available. The warning will be only be printed once per source file in a debug session. These warnings may be disabled by settings set target.process.optimization-warnings false Internally, a new Process::PrintWarning() method has been added for warnings that we want to print only once to the user. It takes a type of warning (currently only eWarningsOptimization) and an object pointer (CompileUnit*) - the warning will only be printed once for a given object pointer value. This is a bit of a prototype of this change - I think we will be tweaking it more in the future. But I wanted to land this and see how it goes. Advanced users will find these warnings unnecessary noise and will quickly disable them - but anyone who maintains a debugger knows that debugging optimized code, without realizing it, is a constant source of confusion and frustation for more typical debugger users. I imagine there will be more of these "warn once per whatever" style warnings that we will want to add in the future and we'll need to come up with a better way for enabling/disabling them. But I'm not srue what form that warning settings should take and I didn't want to code up something that we regret later, so for now I just added another process setting for this one warning. <rdar://problem/19281172> llvm-svn: 244190
2015-08-06 11:27:10 +08:00
{
bool print_warning = true;
StreamSP stream_sp = GetTarget().GetDebugger().GetAsyncOutputStream();
if (stream_sp.get() == nullptr)
return;
if (warning_type == eWarningsOptimization
&& GetWarningsOptimization() == false)
{
return;
}
if (repeat_key != nullptr)
{
WarningsCollection::iterator it = m_warnings_issued.find (warning_type);
if (it == m_warnings_issued.end())
{
m_warnings_issued[warning_type] = WarningsPointerSet();
m_warnings_issued[warning_type].insert (repeat_key);
}
else
{
if (it->second.find (repeat_key) != it->second.end())
{
print_warning = false;
}
else
{
it->second.insert (repeat_key);
}
}
}
if (print_warning)
{
va_list args;
va_start (args, fmt);
stream_sp->PrintfVarArg (fmt, args);
va_end (args);
}
}
Feedback from Jim: Change the "optimized code" warning to be entirely contained within Process so that we won't be duplicating the warning message if other parts of the code want to issue the message. Change Process::PrintWarning to be a protected method - the public method will be the PrintWarningOptimization et al. Also, Have Thread::FunctionOptimizationWarning shortcut out if the warnings have been disabled so that we don't (potentially) compute parts of the SymbolContext unnecessarily. llvm-svn: 244436
2015-08-10 15:55:25 +08:00
void
Process::PrintWarningOptimization (const SymbolContext &sc)
{
if (GetWarningsOptimization() == true
&& sc.module_sp.get()
&& sc.module_sp->GetFileSpec().GetFilename().IsEmpty() == false
&& sc.function
&& sc.function->GetIsOptimized() == true)
{
PrintWarning (Process::Warnings::eWarningsOptimization, sc.module_sp.get(), "%s was compiled with optimization - stepping may behave oddly; variables may not be available.\n", sc.module_sp->GetFileSpec().GetFilename().GetCString());
}
}
Implement ASan history threads in SB API Reviewed at http://reviews.llvm.org/D5219 and http://lists.cs.uiuc.edu/pipermail/lldb-commits/Week-of-Mon-20140901/012809.html llvm-svn: 217300
2014-09-06 09:33:13 +08:00
ThreadCollectionSP
Process::GetHistoryThreads(lldb::addr_t addr)
{
ThreadCollectionSP threads;
Add new virtual method for language runtime plug-ins: virtual void LanguageRuntime::ModulesDidLoad (const ModuleList &module_list); Then reorganized how the objective C plug-in is notified so it will work for all LanguageRuntime subclasses. llvm-svn: 235118
2015-04-17 01:13:34 +08:00
Implement ASan history threads in SB API Reviewed at http://reviews.llvm.org/D5219 and http://lists.cs.uiuc.edu/pipermail/lldb-commits/Week-of-Mon-20140901/012809.html llvm-svn: 217300
2014-09-06 09:33:13 +08:00
const MemoryHistorySP &memory_history = MemoryHistory::FindPlugin(shared_from_this());
if (! memory_history.get()) {
return threads;
}
threads.reset(new ThreadCollection(memory_history->GetHistoryThreads(addr)));
return threads;
}
Add a IsInstrumentationRuntimePresent SB API Reviewed at http://reviews.llvm.org/D5738 This adds an SB API into SBProcess: bool SBProcess::IsInstrumentationRuntimePresent(InstrumentationRuntimeType type); which simply tells whether a particular InstrumentationRuntime (read "ASan") plugin is present and active. llvm-svn: 219560
2014-10-11 09:59:32 +08:00
InstrumentationRuntimeSP
Process::GetInstrumentationRuntime(lldb::InstrumentationRuntimeType type)
{
InstrumentationRuntimeCollection::iterator pos;
pos = m_instrumentation_runtimes.find (type);
if (pos == m_instrumentation_runtimes.end())
{
return InstrumentationRuntimeSP();
}
else
return (*pos).second;
}
Fetch module specification from remote process also Previously the remote module sepcification was fetched only from the remote platform. With this CL if we have a remote process then we ask it if it have any information from a given module. It is required because on android the dynamic linker only reports the name of the SO file and the platform can't always find it without a full path (the process can do it based on /proc/<pid>/maps). Differential revision: http://reviews.llvm.org/D8547 llvm-svn: 233061
2015-03-24 19:15:23 +08:00
bool
Process::GetModuleSpec(const FileSpec& module_file_spec,
const ArchSpec& arch,
ModuleSpec& module_spec)
{
module_spec.Clear();
return false;
}
Fix "process load/unload" on android On android the symbols exposed by libdl (dlopen, dlclose, dlerror) prefixed by "__dl_". This change moves the handling of process load/unload to the platform object and override it for android to handle the special prefix. Differential revision: http://reviews.llvm.org/D11465 llvm-svn: 254504
2015-12-02 19:58:51 +08:00
size_t
Process::AddImageToken(lldb::addr_t image_ptr)
{
m_image_tokens.push_back(image_ptr);
return m_image_tokens.size() - 1;
}
lldb::addr_t
Process::GetImagePtrFromToken(size_t token) const
{
if (token < m_image_tokens.size())
return m_image_tokens[token];
return LLDB_INVALID_IMAGE_TOKEN;
}
void
Process::ResetImageToken(size_t token)
{
if (token < m_image_tokens.size())
m_image_tokens[token] = LLDB_INVALID_IMAGE_TOKEN;
Add a newline at the end of this file llvm-svn: 254666
2015-12-04 07:53:45 +08:00
}
Re-apply r257117 (reverted in r257138 temporarily), with the one change that ThreadPlanStepOut::ThreadPlanStepOut will now only advance the return address breakpoint to the end of a source line, if we have source line debug information. It will not advance to the end of a Symbol if we lack source line information. This, or the recognition of the LEAVE instruction in r257209, would have fixed the regression that Siva was seeing. Both were good changes, so I've made both. Original commit message: Performance improvement: Change lldb so that it puts a breakpoint on the first branch instruction after a function return (or the end of a source line), instead of a breakpoint on the return address, to skip an extra stop & start of the inferior process. I changed Process::AdvanceAddressToNextBranchInstruction to not take an optional InstructionList argument - no callers are providing a cached InstructionList today, and if this function was going to do that, the right thing to do would be to fill out / use a DisassemblerSP which is a disassembler with the InstructionList for this address range. http://reviews.llvm.org/D15708 <rdar://problem/23309838> llvm-svn: 257210
2016-01-09 05:40:11 +08:00
Address
Process::AdvanceAddressToNextBranchInstruction (Address default_stop_addr, AddressRange range_bounds)
{
Target &target = GetTarget();
DisassemblerSP disassembler_sp;
InstructionList *insn_list = NULL;
Address retval = default_stop_addr;
if (target.GetUseFastStepping() == false)
return retval;
if (default_stop_addr.IsValid() == false)
return retval;
ExecutionContext exe_ctx (this);
const char *plugin_name = nullptr;
const char *flavor = nullptr;
const bool prefer_file_cache = true;
disassembler_sp = Disassembler::DisassembleRange(target.GetArchitecture(),
plugin_name,
flavor,
exe_ctx,
range_bounds,
prefer_file_cache);
if (disassembler_sp.get())
insn_list = &disassembler_sp->GetInstructionList();
if (insn_list == NULL)
{
return retval;
}
size_t insn_offset = insn_list->GetIndexOfInstructionAtAddress (default_stop_addr);
if (insn_offset == UINT32_MAX)
{
return retval;
}
uint32_t branch_index = insn_list->GetIndexOfNextBranchInstruction (insn_offset, target);
if (branch_index == UINT32_MAX)
{
return retval;
}
if (branch_index > insn_offset)
{
Address next_branch_insn_address = insn_list->GetInstructionAtIndex (branch_index)->GetAddress();
if (next_branch_insn_address.IsValid() && range_bounds.ContainsFileAddress (next_branch_insn_address))
{
retval = next_branch_insn_address;
}
}
if (disassembler_sp.get())
{
// FIXME: The DisassemblerLLVMC has a reference cycle and won't go away if it has any active instructions.
disassembler_sp->GetInstructionList().Clear();
}
return retval;
}