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

1257 lines
34 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
//===-- SBProcess.cpp -------------------------------------------*- C++ -*-===//
//
// The LLVM Compiler Infrastructure
//
// This file is distributed under the University of Illinois Open Source
// License. See LICENSE.TXT for details.
//
//===----------------------------------------------------------------------===//
Fix Linux build warnings due to redefinition of macros: - add new header lldb-python.h to be included before other system headers - short term fix (eventually python dependencies must be cleaned up) Patch by Matt Kopec! llvm-svn: 169341
2012-12-05 08:20:57 +08:00
#include "lldb/lldb-python.h"
And some more include line fixes. llvm-svn: 105704
2010-06-09 15:44:37 +08:00
#include "lldb/API/SBProcess.h"
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
#include "lldb/lldb-defines.h"
#include "lldb/lldb-types.h"
Move Args.{cpp,h} and Options.{cpp,h} to Interpreter where they really belong. llvm-svn: 106034
2010-06-16 03:49:27 +08:00
#include "lldb/Interpreter/Args.h"
Added the first of hopefully many python example scripts that show how to use the python API that is exposed through SWIG to do some cool stuff. Also fixed synchronous debugging so that all process control APIs exposed through the python API will now wait for the process to stop if you set the async mode to false (see disasm.py). llvm-svn: 115738
2010-10-06 11:53:16 +08:00
#include "lldb/Core/Debugger.h"
First pass at adding logging capabilities for the API functions. At the moment it logs the function calls, their arguments and the return values. This is not complete or polished, but I am committing it now, at the request of someone who really wants to use it, even though it's not really done. It currently does not attempt to log all the functions, just the most important ones. I will be making further adjustments to the API logging code over the next few days/weeks. (Suggestions for improvements are welcome). Update the Python build scripts to re-build the swig C++ file whenever the python-extensions.swig file is modified. Correct the help for 'log enable' command (give it the correct number & type of arguments). llvm-svn: 117349
2010-10-26 11:11:13 +08:00
#include "lldb/Core/Log.h"
<rdar://problem/11757916> Make breakpoint setting by file and line much more efficient by only looking for inlined breakpoint locations if we are setting a breakpoint in anything but a source implementation file. Implementing this complex for a many reasons. Turns out that parsing compile units lazily had some issues with respect to how we need to do things with DWARF in .o files. So the fixes in the checkin for this makes these changes: - Add a new setting called "target.inline-breakpoint-strategy" which can be set to "never", "always", or "headers". "never" will never try and set any inlined breakpoints (fastest). "always" always looks for inlined breakpoint locations (slowest, but most accurate). "headers", which is the default setting, will only look for inlined breakpoint locations if the breakpoint is set in what are consudered to be header files, which is realy defined as "not in an implementation source file". - modify the breakpoint setting by file and line to check the current "target.inline-breakpoint-strategy" setting and act accordingly - Modify compile units to be able to get their language and other info lazily. This allows us to create compile units from the debug map and not have to fill all of the details in, and then lazily discover this information as we go on debuggging. This is needed to avoid parsing all .o files when setting breakpoints in implementation only files (no inlines). Otherwise we would need to parse the .o file, the object file (mach-o in our case) and the symbol file (DWARF in the object file) just to see what the compile unit was. - modify the "SymbolFileDWARFDebugMap" to subclass lldb_private::Module so that the virtual "GetObjectFile()" and "GetSymbolVendor()" functions can be intercepted when the .o file contenst are later lazilly needed. Prior to this fix, when we first instantiated the "SymbolFileDWARFDebugMap" class, we would also make modules, object files and symbol files for every .o file in the debug map because we needed to fix up the sections in the .o files with information that is in the executable debug map. Now we lazily do this in the DebugMapModule::GetObjectFile() Cleaned up header includes a bit as well. llvm-svn: 162860
2012-08-30 05:13:06 +08:00
#include "lldb/Core/Module.h"
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
#include "lldb/Core/State.h"
#include "lldb/Core/Stream.h"
#include "lldb/Core/StreamFile.h"
#include "lldb/Target/Process.h"
#include "lldb/Target/RegisterContext.h"
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
#include "lldb/Target/Target.h"
#include "lldb/Target/Thread.h"
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
// Project includes
And some more include line fixes. llvm-svn: 105704
2010-06-09 15:44:37 +08:00
#include "lldb/API/SBBroadcaster.h"
#include "lldb/API/SBCommandReturnObject.h"
Added the new way we will eventually do all attaches and launches. First clients will fill out either a SBLaunchInfo or SBAttachInfo class, then call: SBProcess SBTarget::Launch (SBLaunchInfo &, SBError &); SBProcess SBTarget::Attach (SBAttachInfo &, SBError &); The attach is working right now and allows the ability to set many filters such as the parent process ID, the user/group ID, the effective user/group ID, and much more. The launch is not yet working, but I will get this working soon. By changing our launch and attach calls to take an object, it allows us to add more capabilities to launching and attaching without having to have launch and attach functions that take more and more arguments. Once this is all working we will deprecated the older launch and attach fucntions and eventually remove them. llvm-svn: 151344
2012-02-24 13:03:03 +08:00
#include "lldb/API/SBDebugger.h"
And some more include line fixes. llvm-svn: 105704
2010-06-09 15:44:37 +08:00
#include "lldb/API/SBEvent.h"
Added the new way we will eventually do all attaches and launches. First clients will fill out either a SBLaunchInfo or SBAttachInfo class, then call: SBProcess SBTarget::Launch (SBLaunchInfo &, SBError &); SBProcess SBTarget::Attach (SBAttachInfo &, SBError &); The attach is working right now and allows the ability to set many filters such as the parent process ID, the user/group ID, the effective user/group ID, and much more. The launch is not yet working, but I will get this working soon. By changing our launch and attach calls to take an object, it allows us to add more capabilities to launching and attaching without having to have launch and attach functions that take more and more arguments. Once this is all working we will deprecated the older launch and attach fucntions and eventually remove them. llvm-svn: 151344
2012-02-24 13:03:03 +08:00
#include "lldb/API/SBFileSpec.h"
And some more include line fixes. llvm-svn: 105704
2010-06-09 15:44:37 +08:00
#include "lldb/API/SBThread.h"
Add GetDescription() and __repr__ () methods to most API classes, to allow "print" from inside Python to print out the objects in a more useful manner. llvm-svn: 114321
2010-09-20 13:20:02 +08:00
#include "lldb/API/SBStream.h"
And some more include line fixes. llvm-svn: 105704
2010-06-09 15:44:37 +08:00
#include "lldb/API/SBStringList.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;
SBProcess::SBProcess () :
<rdar://problem/11791234> Fixed a case where the python interpreter could end up holding onto a previous lldb::SBProcess (probably in lldb.process) when run under Xcode. Prior to this fix, the lldb::SBProcess held onto a shared pointer to a lldb_private::Process. This in turn could cause the process to still have a thread list with stack frames. The stack frames would have module shared pointers in the lldb_private::SymbolContext objects. We also had issues with things staying in the shared module list too long when we found things by UUID (we didn't remove the out of date ModuleSP from the global module cache). Now all of this is fixed and everything goes away between runs. llvm-svn: 160140
2012-07-13 04:32:19 +08:00
m_opaque_wp()
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
{
}
//----------------------------------------------------------------------
// SBProcess constructor
//----------------------------------------------------------------------
SBProcess::SBProcess (const SBProcess& rhs) :
<rdar://problem/11791234> Fixed a case where the python interpreter could end up holding onto a previous lldb::SBProcess (probably in lldb.process) when run under Xcode. Prior to this fix, the lldb::SBProcess held onto a shared pointer to a lldb_private::Process. This in turn could cause the process to still have a thread list with stack frames. The stack frames would have module shared pointers in the lldb_private::SymbolContext objects. We also had issues with things staying in the shared module list too long when we found things by UUID (we didn't remove the out of date ModuleSP from the global module cache). Now all of this is fixed and everything goes away between runs. llvm-svn: 160140
2012-07-13 04:32:19 +08:00
m_opaque_wp (rhs.m_opaque_wp)
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
{
}
SBProcess::SBProcess (const lldb::ProcessSP &process_sp) :
<rdar://problem/11791234> Fixed a case where the python interpreter could end up holding onto a previous lldb::SBProcess (probably in lldb.process) when run under Xcode. Prior to this fix, the lldb::SBProcess held onto a shared pointer to a lldb_private::Process. This in turn could cause the process to still have a thread list with stack frames. The stack frames would have module shared pointers in the lldb_private::SymbolContext objects. We also had issues with things staying in the shared module list too long when we found things by UUID (we didn't remove the out of date ModuleSP from the global module cache). Now all of this is fixed and everything goes away between runs. llvm-svn: 160140
2012-07-13 04:32:19 +08:00
m_opaque_wp (process_sp)
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
{
}
Added copy constructors and assignment operators to all lldb::SB* classes so we don't end up with weak exports with some compilers. llvm-svn: 118312
2010-11-06 07:17:00 +08:00
const SBProcess&
SBProcess::operator = (const SBProcess& rhs)
{
if (this != &rhs)
<rdar://problem/11791234> Fixed a case where the python interpreter could end up holding onto a previous lldb::SBProcess (probably in lldb.process) when run under Xcode. Prior to this fix, the lldb::SBProcess held onto a shared pointer to a lldb_private::Process. This in turn could cause the process to still have a thread list with stack frames. The stack frames would have module shared pointers in the lldb_private::SymbolContext objects. We also had issues with things staying in the shared module list too long when we found things by UUID (we didn't remove the out of date ModuleSP from the global module cache). Now all of this is fixed and everything goes away between runs. llvm-svn: 160140
2012-07-13 04:32:19 +08:00
m_opaque_wp = rhs.m_opaque_wp;
Added copy constructors and assignment operators to all lldb::SB* classes so we don't end up with weak exports with some compilers. llvm-svn: 118312
2010-11-06 07:17:00 +08:00
return *this;
}
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
//----------------------------------------------------------------------
// Destructor
//----------------------------------------------------------------------
SBProcess::~SBProcess()
{
}
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
const char *
SBProcess::GetBroadcasterClassName ()
{
return Process::GetStaticBroadcasterClass().AsCString();
}
Add API to get the process plugin name & short name. llvm-svn: 166799
2012-10-27 03:18:04 +08:00
const char *
SBProcess::GetPluginName ()
{
ProcessSP process_sp(GetSP());
if (process_sp)
{
<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
return process_sp->GetPluginName().GetCString();
Add API to get the process plugin name & short name. llvm-svn: 166799
2012-10-27 03:18:04 +08:00
}
return "<Unknown>";
}
const char *
SBProcess::GetShortPluginName ()
{
ProcessSP process_sp(GetSP());
if (process_sp)
{
<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
return process_sp->GetPluginName().GetCString();
Add API to get the process plugin name & short name. llvm-svn: 166799
2012-10-27 03:18:04 +08:00
}
return "<Unknown>";
}
SBFrame is now threadsafe using some extra tricks. One issue is that stack frames might go away (the object itself, not the actual logical frame) when we are single stepping due to the way we currently sometimes end up flushing frames when stepping in/out/over. They later will come back to life represented by another object yet they have the same StackID. Now when you get a lldb::SBFrame object, it will track the frame it is initialized with until the thread goes away or the StackID no longer exists in the stack for the thread it was created on. It uses a weak_ptr to both the frame and thread and also stores the StackID. These three items allow us to determine when the stack frame object has gone away (the weak_ptr will be NULL) and allows us to find the correct frame again. In our test suite we had such cases where we were just getting lucky when something like this happened: 1 - stop at breakpoint 2 - get first frame in thread where we stopped 3 - run an expression that causes the program to JIT and run code 4 - run more expressions on the frame from step 2 which was very very luckily still around inside a shared pointer, yet, not part of the current thread (a new stack frame object had appeared with the same stack ID and depth). We now avoid all such issues and properly keep up to date, or we start returning errors when the frame doesn't exist and always responds with invalid answers. Also fixed the UserSettingsController (not going to rewrite this just yet) so that it doesn't crash on shutdown. Using weak_ptr's came in real handy to track when the master controller has already gone away and this allowed me to pull out the previous NotifyOwnerIsShuttingDown() patch as it is no longer needed. llvm-svn: 149231
2012-01-30 15:41:31 +08:00
lldb::ProcessSP
SBProcess::GetSP() const
{
<rdar://problem/11791234> Fixed a case where the python interpreter could end up holding onto a previous lldb::SBProcess (probably in lldb.process) when run under Xcode. Prior to this fix, the lldb::SBProcess held onto a shared pointer to a lldb_private::Process. This in turn could cause the process to still have a thread list with stack frames. The stack frames would have module shared pointers in the lldb_private::SymbolContext objects. We also had issues with things staying in the shared module list too long when we found things by UUID (we didn't remove the out of date ModuleSP from the global module cache). Now all of this is fixed and everything goes away between runs. llvm-svn: 160140
2012-07-13 04:32:19 +08:00
return m_opaque_wp.lock();
SBFrame is now threadsafe using some extra tricks. One issue is that stack frames might go away (the object itself, not the actual logical frame) when we are single stepping due to the way we currently sometimes end up flushing frames when stepping in/out/over. They later will come back to life represented by another object yet they have the same StackID. Now when you get a lldb::SBFrame object, it will track the frame it is initialized with until the thread goes away or the StackID no longer exists in the stack for the thread it was created on. It uses a weak_ptr to both the frame and thread and also stores the StackID. These three items allow us to determine when the stack frame object has gone away (the weak_ptr will be NULL) and allows us to find the correct frame again. In our test suite we had such cases where we were just getting lucky when something like this happened: 1 - stop at breakpoint 2 - get first frame in thread where we stopped 3 - run an expression that causes the program to JIT and run code 4 - run more expressions on the frame from step 2 which was very very luckily still around inside a shared pointer, yet, not part of the current thread (a new stack frame object had appeared with the same stack ID and depth). We now avoid all such issues and properly keep up to date, or we start returning errors when the frame doesn't exist and always responds with invalid answers. Also fixed the UserSettingsController (not going to rewrite this just yet) so that it doesn't crash on shutdown. Using weak_ptr's came in real handy to track when the master controller has already gone away and this allowed me to pull out the previous NotifyOwnerIsShuttingDown() patch as it is no longer needed. llvm-svn: 149231
2012-01-30 15:41:31 +08:00
}
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
void
SBFrame is now threadsafe using some extra tricks. One issue is that stack frames might go away (the object itself, not the actual logical frame) when we are single stepping due to the way we currently sometimes end up flushing frames when stepping in/out/over. They later will come back to life represented by another object yet they have the same StackID. Now when you get a lldb::SBFrame object, it will track the frame it is initialized with until the thread goes away or the StackID no longer exists in the stack for the thread it was created on. It uses a weak_ptr to both the frame and thread and also stores the StackID. These three items allow us to determine when the stack frame object has gone away (the weak_ptr will be NULL) and allows us to find the correct frame again. In our test suite we had such cases where we were just getting lucky when something like this happened: 1 - stop at breakpoint 2 - get first frame in thread where we stopped 3 - run an expression that causes the program to JIT and run code 4 - run more expressions on the frame from step 2 which was very very luckily still around inside a shared pointer, yet, not part of the current thread (a new stack frame object had appeared with the same stack ID and depth). We now avoid all such issues and properly keep up to date, or we start returning errors when the frame doesn't exist and always responds with invalid answers. Also fixed the UserSettingsController (not going to rewrite this just yet) so that it doesn't crash on shutdown. Using weak_ptr's came in real handy to track when the master controller has already gone away and this allowed me to pull out the previous NotifyOwnerIsShuttingDown() patch as it is no longer needed. llvm-svn: 149231
2012-01-30 15:41:31 +08:00
SBProcess::SetSP (const ProcessSP &process_sp)
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
{
<rdar://problem/11791234> Fixed a case where the python interpreter could end up holding onto a previous lldb::SBProcess (probably in lldb.process) when run under Xcode. Prior to this fix, the lldb::SBProcess held onto a shared pointer to a lldb_private::Process. This in turn could cause the process to still have a thread list with stack frames. The stack frames would have module shared pointers in the lldb_private::SymbolContext objects. We also had issues with things staying in the shared module list too long when we found things by UUID (we didn't remove the out of date ModuleSP from the global module cache). Now all of this is fixed and everything goes away between runs. llvm-svn: 160140
2012-07-13 04:32:19 +08:00
m_opaque_wp = process_sp;
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
void
SBProcess::Clear ()
{
<rdar://problem/11791234> Fixed a case where the python interpreter could end up holding onto a previous lldb::SBProcess (probably in lldb.process) when run under Xcode. Prior to this fix, the lldb::SBProcess held onto a shared pointer to a lldb_private::Process. This in turn could cause the process to still have a thread list with stack frames. The stack frames would have module shared pointers in the lldb_private::SymbolContext objects. We also had issues with things staying in the shared module list too long when we found things by UUID (we didn't remove the out of date ModuleSP from the global module cache). Now all of this is fixed and everything goes away between runs. llvm-svn: 160140
2012-07-13 04:32:19 +08:00
m_opaque_wp.reset();
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
bool
SBProcess::IsValid() const
{
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
ProcessSP process_sp(m_opaque_wp.lock());
return ((bool) process_sp && process_sp->IsValid());
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
Expose ConnectRemote API through SBTarget and SBProcess. Patch verified by Greg Clayton prior to checkin. llvm-svn: 126974
2011-03-04 08:31:13 +08:00
bool
SBProcess::RemoteLaunch (char const **argv,
char const **envp,
const char *stdin_path,
const char *stdout_path,
const char *stderr_path,
const char *working_directory,
uint32_t launch_flags,
bool stop_at_entry,
lldb::SBError& 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_API));
Expose ConnectRemote API through SBTarget and SBProcess. Patch verified by Greg Clayton prior to checkin. llvm-svn: 126974
2011-03-04 08:31:13 +08:00
if (log) {
log->Printf ("SBProcess(%p)::RemoteLaunch (argv=%p, envp=%p, stdin=%s, stdout=%s, stderr=%s, working-dir=%s, launch_flags=0x%x, stop_at_entry=%i, &error (%p))...",
<rdar://problem/11791234> Fixed a case where the python interpreter could end up holding onto a previous lldb::SBProcess (probably in lldb.process) when run under Xcode. Prior to this fix, the lldb::SBProcess held onto a shared pointer to a lldb_private::Process. This in turn could cause the process to still have a thread list with stack frames. The stack frames would have module shared pointers in the lldb_private::SymbolContext objects. We also had issues with things staying in the shared module list too long when we found things by UUID (we didn't remove the out of date ModuleSP from the global module cache). Now all of this is fixed and everything goes away between runs. llvm-svn: 160140
2012-07-13 04:32:19 +08:00
m_opaque_wp.lock().get(),
Expose ConnectRemote API through SBTarget and SBProcess. Patch verified by Greg Clayton prior to checkin. llvm-svn: 126974
2011-03-04 08:31:13 +08:00
argv,
envp,
stdin_path ? stdin_path : "NULL",
stdout_path ? stdout_path : "NULL",
stderr_path ? stderr_path : "NULL",
working_directory ? working_directory : "NULL",
launch_flags,
stop_at_entry,
error.get());
}
lldb::SBTarget and lldb::SBProcess are now thread hardened. They both still contain shared pointers to the lldb_private::Target and lldb_private::Process objects respectively as we won't want the target or process just going away. Also cleaned up the lldb::SBModule to remove dangerous pointer accessors. For any code the public API files, we should always be grabbing shared pointers to any objects for the current class, and any other classes prior to running code with them. llvm-svn: 149238
2012-01-30 17:04:36 +08:00
ProcessSP process_sp(GetSP());
if (process_sp)
Expose ConnectRemote API through SBTarget and SBProcess. Patch verified by Greg Clayton prior to checkin. llvm-svn: 126974
2011-03-04 08:31:13 +08:00
{
Added logging when API calls try to do something that shouldn't be done when the process is stopped by having logging calls that end with "error: process is running". Also test for the process to be stopped when many SBValue API calls are made to make sure it is safe to evaluate values, children of values and much more. llvm-svn: 154160
2012-04-06 10:17:47 +08:00
Mutex::Locker api_locker (process_sp->GetTarget().GetAPIMutex());
if (process_sp->GetState() == eStateConnected)
Expose ConnectRemote API through SBTarget and SBProcess. Patch verified by Greg Clayton prior to checkin. llvm-svn: 126974
2011-03-04 08:31:13 +08:00
{
Added logging when API calls try to do something that shouldn't be done when the process is stopped by having logging calls that end with "error: process is running". Also test for the process to be stopped when many SBValue API calls are made to make sure it is safe to evaluate values, children of values and much more. llvm-svn: 154160
2012-04-06 10:17:47 +08:00
if (stop_at_entry)
launch_flags |= eLaunchFlagStopAtEntry;
ProcessLaunchInfo launch_info (stdin_path,
stdout_path,
stderr_path,
working_directory,
launch_flags);
Module *exe_module = process_sp->GetTarget().GetExecutableModulePointer();
if (exe_module)
launch_info.SetExecutableFile(exe_module->GetFileSpec(), true);
if (argv)
launch_info.GetArguments().AppendArguments (argv);
if (envp)
launch_info.GetEnvironmentEntries ().SetArguments (envp);
error.SetError (process_sp->Launch (launch_info));
Expose ConnectRemote API through SBTarget and SBProcess. Patch verified by Greg Clayton prior to checkin. llvm-svn: 126974
2011-03-04 08:31:13 +08:00
}
else
{
Added logging when API calls try to do something that shouldn't be done when the process is stopped by having logging calls that end with "error: process is running". Also test for the process to be stopped when many SBValue API calls are made to make sure it is safe to evaluate values, children of values and much more. llvm-svn: 154160
2012-04-06 10:17:47 +08:00
error.SetErrorString ("must be in eStateConnected to call RemoteLaunch");
Expose ConnectRemote API through SBTarget and SBProcess. Patch verified by Greg Clayton prior to checkin. llvm-svn: 126974
2011-03-04 08:31:13 +08:00
}
}
else
{
error.SetErrorString ("unable to attach pid");
}
if (log) {
SBStream sstr;
error.GetDescription (sstr);
lldb::SBTarget and lldb::SBProcess are now thread hardened. They both still contain shared pointers to the lldb_private::Target and lldb_private::Process objects respectively as we won't want the target or process just going away. Also cleaned up the lldb::SBModule to remove dangerous pointer accessors. For any code the public API files, we should always be grabbing shared pointers to any objects for the current class, and any other classes prior to running code with them. llvm-svn: 149238
2012-01-30 17:04:36 +08:00
log->Printf ("SBProcess(%p)::RemoteLaunch (...) => SBError (%p): %s", process_sp.get(), error.get(), sstr.GetData());
Expose ConnectRemote API through SBTarget and SBProcess. Patch verified by Greg Clayton prior to checkin. llvm-svn: 126974
2011-03-04 08:31:13 +08:00
}
return error.Success();
}
bool
SBProcess::RemoteAttachToProcessWithID (lldb::pid_t pid, lldb::SBError& error)
{
lldb::SBTarget and lldb::SBProcess are now thread hardened. They both still contain shared pointers to the lldb_private::Target and lldb_private::Process objects respectively as we won't want the target or process just going away. Also cleaned up the lldb::SBModule to remove dangerous pointer accessors. For any code the public API files, we should always be grabbing shared pointers to any objects for the current class, and any other classes prior to running code with them. llvm-svn: 149238
2012-01-30 17:04:36 +08:00
ProcessSP process_sp(GetSP());
if (process_sp)
Expose ConnectRemote API through SBTarget and SBProcess. Patch verified by Greg Clayton prior to checkin. llvm-svn: 126974
2011-03-04 08:31:13 +08:00
{
Added logging when API calls try to do something that shouldn't be done when the process is stopped by having logging calls that end with "error: process is running". Also test for the process to be stopped when many SBValue API calls are made to make sure it is safe to evaluate values, children of values and much more. llvm-svn: 154160
2012-04-06 10:17:47 +08:00
Mutex::Locker api_locker (process_sp->GetTarget().GetAPIMutex());
if (process_sp->GetState() == eStateConnected)
Expose ConnectRemote API through SBTarget and SBProcess. Patch verified by Greg Clayton prior to checkin. llvm-svn: 126974
2011-03-04 08:31:13 +08:00
{
Added logging when API calls try to do something that shouldn't be done when the process is stopped by having logging calls that end with "error: process is running". Also test for the process to be stopped when many SBValue API calls are made to make sure it is safe to evaluate values, children of values and much more. llvm-svn: 154160
2012-04-06 10:17:47 +08:00
ProcessAttachInfo attach_info;
attach_info.SetProcessID (pid);
error.SetError (process_sp->Attach (attach_info));
Expose ConnectRemote API through SBTarget and SBProcess. Patch verified by Greg Clayton prior to checkin. llvm-svn: 126974
2011-03-04 08:31:13 +08:00
}
else
{
Added logging when API calls try to do something that shouldn't be done when the process is stopped by having logging calls that end with "error: process is running". Also test for the process to be stopped when many SBValue API calls are made to make sure it is safe to evaluate values, children of values and much more. llvm-svn: 154160
2012-04-06 10:17:47 +08:00
error.SetErrorString ("must be in eStateConnected to call RemoteAttachToProcessWithID");
Expose ConnectRemote API through SBTarget and SBProcess. Patch verified by Greg Clayton prior to checkin. llvm-svn: 126974
2011-03-04 08:31:13 +08:00
}
}
else
{
error.SetErrorString ("unable to attach pid");
}
<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_API));
Expose ConnectRemote API through SBTarget and SBProcess. Patch verified by Greg Clayton prior to checkin. llvm-svn: 126974
2011-03-04 08:31:13 +08:00
if (log) {
SBStream sstr;
error.GetDescription (sstr);
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 ("SBProcess(%p)::RemoteAttachToProcessWithID (%" PRIu64 ") => SBError (%p): %s", process_sp.get(), pid, error.get(), sstr.GetData());
Expose ConnectRemote API through SBTarget and SBProcess. Patch verified by Greg Clayton prior to checkin. llvm-svn: 126974
2011-03-04 08:31:13 +08:00
}
return error.Success();
}
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
uint32_t
SBProcess::GetNumThreads ()
{
<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_API));
First pass at adding logging capabilities for the API functions. At the moment it logs the function calls, their arguments and the return values. This is not complete or polished, but I am committing it now, at the request of someone who really wants to use it, even though it's not really done. It currently does not attempt to log all the functions, just the most important ones. I will be making further adjustments to the API logging code over the next few days/weeks. (Suggestions for improvements are welcome). Update the Python build scripts to re-build the swig C++ file whenever the python-extensions.swig file is modified. Correct the help for 'log enable' command (give it the correct number & type of arguments). llvm-svn: 117349
2010-10-26 11:11:13 +08:00
uint32_t num_threads = 0;
lldb::SBTarget and lldb::SBProcess are now thread hardened. They both still contain shared pointers to the lldb_private::Target and lldb_private::Process objects respectively as we won't want the target or process just going away. Also cleaned up the lldb::SBModule to remove dangerous pointer accessors. For any code the public API files, we should always be grabbing shared pointers to any objects for the current class, and any other classes prior to running code with them. llvm-svn: 149238
2012-01-30 17:04:36 +08:00
ProcessSP process_sp(GetSP());
if (process_sp)
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +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
Process::StopLocker stop_locker;
const bool can_update = stop_locker.TryLock(&process_sp->GetRunLock());
lldb::SBTarget and lldb::SBProcess are now thread hardened. They both still contain shared pointers to the lldb_private::Target and lldb_private::Process objects respectively as we won't want the target or process just going away. Also cleaned up the lldb::SBModule to remove dangerous pointer accessors. For any code the public API files, we should always be grabbing shared pointers to any objects for the current class, and any other classes prior to running code with them. llvm-svn: 149238
2012-01-30 17:04:36 +08:00
Mutex::Locker api_locker (process_sp->GetTarget().GetAPIMutex());
num_threads = process_sp->GetThreadList().GetSize(can_update);
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
First pass at adding logging capabilities for the API functions. At the moment it logs the function calls, their arguments and the return values. This is not complete or polished, but I am committing it now, at the request of someone who really wants to use it, even though it's not really done. It currently does not attempt to log all the functions, just the most important ones. I will be making further adjustments to the API logging code over the next few days/weeks. (Suggestions for improvements are welcome). Update the Python build scripts to re-build the swig C++ file whenever the python-extensions.swig file is modified. Correct the help for 'log enable' command (give it the correct number & type of arguments). llvm-svn: 117349
2010-10-26 11:11:13 +08:00
if (log)
lldb::SBTarget and lldb::SBProcess are now thread hardened. They both still contain shared pointers to the lldb_private::Target and lldb_private::Process objects respectively as we won't want the target or process just going away. Also cleaned up the lldb::SBModule to remove dangerous pointer accessors. For any code the public API files, we should always be grabbing shared pointers to any objects for the current class, and any other classes prior to running code with them. llvm-svn: 149238
2012-01-30 17:04:36 +08:00
log->Printf ("SBProcess(%p)::GetNumThreads () => %d", process_sp.get(), num_threads);
First pass at adding logging capabilities for the API functions. At the moment it logs the function calls, their arguments and the return values. This is not complete or polished, but I am committing it now, at the request of someone who really wants to use it, even though it's not really done. It currently does not attempt to log all the functions, just the most important ones. I will be making further adjustments to the API logging code over the next few days/weeks. (Suggestions for improvements are welcome). Update the Python build scripts to re-build the swig C++ file whenever the python-extensions.swig file is modified. Correct the help for 'log enable' command (give it the correct number & type of arguments). llvm-svn: 117349
2010-10-26 11:11:13 +08:00
return num_threads;
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
SBThread
Change "Current" as in GetCurrentThread, GetCurrentStackFrame, etc, to "Selected" i.e. GetSelectedThread. Selected makes more sense, since these are set by some user action (a selection). I didn't change "CurrentProcess" since this is always controlled by the target, and a given target can only have one process, so it really can't be selected. llvm-svn: 112221
2010-08-27 05:32:51 +08:00
SBProcess::GetSelectedThread () const
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_API));
First pass at adding logging capabilities for the API functions. At the moment it logs the function calls, their arguments and the return values. This is not complete or polished, but I am committing it now, at the request of someone who really wants to use it, even though it's not really done. It currently does not attempt to log all the functions, just the most important ones. I will be making further adjustments to the API logging code over the next few days/weeks. (Suggestions for improvements are welcome). Update the Python build scripts to re-build the swig C++ file whenever the python-extensions.swig file is modified. Correct the help for 'log enable' command (give it the correct number & type of arguments). llvm-svn: 117349
2010-10-26 11:11:13 +08:00
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
SBThread sb_thread;
Removed the "lldb-forward-rtti.h" header file as it was designed to contain all RTTI types, and since we don't use RTTI anymore since clang and llvm don't we don't really need this header file. All shared pointer definitions have been moved into "lldb-forward.h". Defined std::tr1::weak_ptr definitions for all of the types that inherit from enable_shared_from_this() in "lldb-forward.h" in preparation for thread hardening our public API. The first in the thread hardening check-ins. First we start with SBThread. We have issues in our lldb::SB API right now where if you have one object that is being used by two threads we have a race condition. Consider the following code: 1 int 2 SBThread::SomeFunction() 3 { 4 int result = -1; 5 if (m_opaque_sp) 6 { 7 result = m_opaque_sp->DoSomething(); 8 } 9 return result; 10 } And now this happens: Thread 1 enters any SBThread function and checks its m_opaque_sp and is about to execute the code on line 7 but hasn't yet Thread 2 gets to run and class sb_thread.Clear() which calls m_opaque_sp.clear() and clears the contents of the shared pointer member Thread 1 now crashes when it resumes. The solution is to use std::tr1::weak_ptr. Now the SBThread class contains a lldb::ThreadWP (weak pointer to our lldb_private::Thread class) and this function would look like: 1 int 2 SBThread::SomeFunction() 3 { 4 int result = -1; 5 ThreadSP thread_sp(m_opaque_wp.lock()); 6 if (thread_sp) 7 { 8 result = m_opaque_sp->DoSomething(); 9 } 10 return result; 11 } Now we have a solid thread safe API where we get a local copy of our thread shared pointer from our weak_ptr and then we are guaranteed it can't go away during our function. So lldb::SBThread has been thread hardened, more checkins to follow shortly. llvm-svn: 149218
2012-01-30 10:53:15 +08:00
ThreadSP thread_sp;
lldb::SBTarget and lldb::SBProcess are now thread hardened. They both still contain shared pointers to the lldb_private::Target and lldb_private::Process objects respectively as we won't want the target or process just going away. Also cleaned up the lldb::SBModule to remove dangerous pointer accessors. For any code the public API files, we should always be grabbing shared pointers to any objects for the current class, and any other classes prior to running code with them. llvm-svn: 149238
2012-01-30 17:04:36 +08:00
ProcessSP process_sp(GetSP());
if (process_sp)
The LLDB API (lldb::SB*) is now thread safe! llvm-svn: 122262
2010-12-21 04:49:23 +08:00
{
lldb::SBTarget and lldb::SBProcess are now thread hardened. They both still contain shared pointers to the lldb_private::Target and lldb_private::Process objects respectively as we won't want the target or process just going away. Also cleaned up the lldb::SBModule to remove dangerous pointer accessors. For any code the public API files, we should always be grabbing shared pointers to any objects for the current class, and any other classes prior to running code with them. llvm-svn: 149238
2012-01-30 17:04:36 +08:00
Mutex::Locker api_locker (process_sp->GetTarget().GetAPIMutex());
thread_sp = process_sp->GetThreadList().GetSelectedThread();
Removed the "lldb-forward-rtti.h" header file as it was designed to contain all RTTI types, and since we don't use RTTI anymore since clang and llvm don't we don't really need this header file. All shared pointer definitions have been moved into "lldb-forward.h". Defined std::tr1::weak_ptr definitions for all of the types that inherit from enable_shared_from_this() in "lldb-forward.h" in preparation for thread hardening our public API. The first in the thread hardening check-ins. First we start with SBThread. We have issues in our lldb::SB API right now where if you have one object that is being used by two threads we have a race condition. Consider the following code: 1 int 2 SBThread::SomeFunction() 3 { 4 int result = -1; 5 if (m_opaque_sp) 6 { 7 result = m_opaque_sp->DoSomething(); 8 } 9 return result; 10 } And now this happens: Thread 1 enters any SBThread function and checks its m_opaque_sp and is about to execute the code on line 7 but hasn't yet Thread 2 gets to run and class sb_thread.Clear() which calls m_opaque_sp.clear() and clears the contents of the shared pointer member Thread 1 now crashes when it resumes. The solution is to use std::tr1::weak_ptr. Now the SBThread class contains a lldb::ThreadWP (weak pointer to our lldb_private::Thread class) and this function would look like: 1 int 2 SBThread::SomeFunction() 3 { 4 int result = -1; 5 ThreadSP thread_sp(m_opaque_wp.lock()); 6 if (thread_sp) 7 { 8 result = m_opaque_sp->DoSomething(); 9 } 10 return result; 11 } Now we have a solid thread safe API where we get a local copy of our thread shared pointer from our weak_ptr and then we are guaranteed it can't go away during our function. So lldb::SBThread has been thread hardened, more checkins to follow shortly. llvm-svn: 149218
2012-01-30 10:53:15 +08:00
sb_thread.SetThread (thread_sp);
The LLDB API (lldb::SB*) is now thread safe! llvm-svn: 122262
2010-12-21 04:49:23 +08:00
}
First pass at adding logging capabilities for the API functions. At the moment it logs the function calls, their arguments and the return values. This is not complete or polished, but I am committing it now, at the request of someone who really wants to use it, even though it's not really done. It currently does not attempt to log all the functions, just the most important ones. I will be making further adjustments to the API logging code over the next few days/weeks. (Suggestions for improvements are welcome). Update the Python build scripts to re-build the swig C++ file whenever the python-extensions.swig file is modified. Correct the help for 'log enable' command (give it the correct number & type of arguments). llvm-svn: 117349
2010-10-26 11:11:13 +08:00
if (log)
{
lldb::SBTarget and lldb::SBProcess are now thread hardened. They both still contain shared pointers to the lldb_private::Target and lldb_private::Process objects respectively as we won't want the target or process just going away. Also cleaned up the lldb::SBModule to remove dangerous pointer accessors. For any code the public API files, we should always be grabbing shared pointers to any objects for the current class, and any other classes prior to running code with them. llvm-svn: 149238
2012-01-30 17:04:36 +08:00
log->Printf ("SBProcess(%p)::GetSelectedThread () => SBThread(%p)", process_sp.get(), thread_sp.get());
First pass at adding logging capabilities for the API functions. At the moment it logs the function calls, their arguments and the return values. This is not complete or polished, but I am committing it now, at the request of someone who really wants to use it, even though it's not really done. It currently does not attempt to log all the functions, just the most important ones. I will be making further adjustments to the API logging code over the next few days/weeks. (Suggestions for improvements are welcome). Update the Python build scripts to re-build the swig C++ file whenever the python-extensions.swig file is modified. Correct the help for 'log enable' command (give it the correct number & type of arguments). llvm-svn: 117349
2010-10-26 11:11:13 +08:00
}
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
return sb_thread;
}
<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
SBThread
SBProcess::CreateOSPluginThread (lldb::tid_t tid, lldb::addr_t context)
{
<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_API));
<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
SBThread sb_thread;
ThreadSP thread_sp;
ProcessSP process_sp(GetSP());
if (process_sp)
{
Mutex::Locker api_locker (process_sp->GetTarget().GetAPIMutex());
thread_sp = process_sp->CreateOSPluginThread(tid, context);
sb_thread.SetThread (thread_sp);
}
if (log)
log->Printf ("SBProcess(%p)::CreateOSPluginThread (tid=0x%" PRIx64 ", context=0x%" PRIx64 ") => SBThread(%p)", process_sp.get(), tid, context, thread_sp.get());
return sb_thread;
}
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
SBTarget
SBProcess::GetTarget() const
{
<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_API));
First pass at adding logging capabilities for the API functions. At the moment it logs the function calls, their arguments and the return values. This is not complete or polished, but I am committing it now, at the request of someone who really wants to use it, even though it's not really done. It currently does not attempt to log all the functions, just the most important ones. I will be making further adjustments to the API logging code over the next few days/weeks. (Suggestions for improvements are welcome). Update the Python build scripts to re-build the swig C++ file whenever the python-extensions.swig file is modified. Correct the help for 'log enable' command (give it the correct number & type of arguments). llvm-svn: 117349
2010-10-26 11:11:13 +08:00
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
SBTarget sb_target;
SBFrame is now threadsafe using some extra tricks. One issue is that stack frames might go away (the object itself, not the actual logical frame) when we are single stepping due to the way we currently sometimes end up flushing frames when stepping in/out/over. They later will come back to life represented by another object yet they have the same StackID. Now when you get a lldb::SBFrame object, it will track the frame it is initialized with until the thread goes away or the StackID no longer exists in the stack for the thread it was created on. It uses a weak_ptr to both the frame and thread and also stores the StackID. These three items allow us to determine when the stack frame object has gone away (the weak_ptr will be NULL) and allows us to find the correct frame again. In our test suite we had such cases where we were just getting lucky when something like this happened: 1 - stop at breakpoint 2 - get first frame in thread where we stopped 3 - run an expression that causes the program to JIT and run code 4 - run more expressions on the frame from step 2 which was very very luckily still around inside a shared pointer, yet, not part of the current thread (a new stack frame object had appeared with the same stack ID and depth). We now avoid all such issues and properly keep up to date, or we start returning errors when the frame doesn't exist and always responds with invalid answers. Also fixed the UserSettingsController (not going to rewrite this just yet) so that it doesn't crash on shutdown. Using weak_ptr's came in real handy to track when the master controller has already gone away and this allowed me to pull out the previous NotifyOwnerIsShuttingDown() patch as it is no longer needed. llvm-svn: 149231
2012-01-30 15:41:31 +08:00
TargetSP target_sp;
lldb::SBTarget and lldb::SBProcess are now thread hardened. They both still contain shared pointers to the lldb_private::Target and lldb_private::Process objects respectively as we won't want the target or process just going away. Also cleaned up the lldb::SBModule to remove dangerous pointer accessors. For any code the public API files, we should always be grabbing shared pointers to any objects for the current class, and any other classes prior to running code with them. llvm-svn: 149238
2012-01-30 17:04:36 +08:00
ProcessSP process_sp(GetSP());
if (process_sp)
SBFrame is now threadsafe using some extra tricks. One issue is that stack frames might go away (the object itself, not the actual logical frame) when we are single stepping due to the way we currently sometimes end up flushing frames when stepping in/out/over. They later will come back to life represented by another object yet they have the same StackID. Now when you get a lldb::SBFrame object, it will track the frame it is initialized with until the thread goes away or the StackID no longer exists in the stack for the thread it was created on. It uses a weak_ptr to both the frame and thread and also stores the StackID. These three items allow us to determine when the stack frame object has gone away (the weak_ptr will be NULL) and allows us to find the correct frame again. In our test suite we had such cases where we were just getting lucky when something like this happened: 1 - stop at breakpoint 2 - get first frame in thread where we stopped 3 - run an expression that causes the program to JIT and run code 4 - run more expressions on the frame from step 2 which was very very luckily still around inside a shared pointer, yet, not part of the current thread (a new stack frame object had appeared with the same stack ID and depth). We now avoid all such issues and properly keep up to date, or we start returning errors when the frame doesn't exist and always responds with invalid answers. Also fixed the UserSettingsController (not going to rewrite this just yet) so that it doesn't crash on shutdown. Using weak_ptr's came in real handy to track when the master controller has already gone away and this allowed me to pull out the previous NotifyOwnerIsShuttingDown() patch as it is no longer needed. llvm-svn: 149231
2012-01-30 15:41:31 +08:00
{
lldb::SBTarget and lldb::SBProcess are now thread hardened. They both still contain shared pointers to the lldb_private::Target and lldb_private::Process objects respectively as we won't want the target or process just going away. Also cleaned up the lldb::SBModule to remove dangerous pointer accessors. For any code the public API files, we should always be grabbing shared pointers to any objects for the current class, and any other classes prior to running code with them. llvm-svn: 149238
2012-01-30 17:04:36 +08:00
target_sp = process_sp->GetTarget().shared_from_this();
SBFrame is now threadsafe using some extra tricks. One issue is that stack frames might go away (the object itself, not the actual logical frame) when we are single stepping due to the way we currently sometimes end up flushing frames when stepping in/out/over. They later will come back to life represented by another object yet they have the same StackID. Now when you get a lldb::SBFrame object, it will track the frame it is initialized with until the thread goes away or the StackID no longer exists in the stack for the thread it was created on. It uses a weak_ptr to both the frame and thread and also stores the StackID. These three items allow us to determine when the stack frame object has gone away (the weak_ptr will be NULL) and allows us to find the correct frame again. In our test suite we had such cases where we were just getting lucky when something like this happened: 1 - stop at breakpoint 2 - get first frame in thread where we stopped 3 - run an expression that causes the program to JIT and run code 4 - run more expressions on the frame from step 2 which was very very luckily still around inside a shared pointer, yet, not part of the current thread (a new stack frame object had appeared with the same stack ID and depth). We now avoid all such issues and properly keep up to date, or we start returning errors when the frame doesn't exist and always responds with invalid answers. Also fixed the UserSettingsController (not going to rewrite this just yet) so that it doesn't crash on shutdown. Using weak_ptr's came in real handy to track when the master controller has already gone away and this allowed me to pull out the previous NotifyOwnerIsShuttingDown() patch as it is no longer needed. llvm-svn: 149231
2012-01-30 15:41:31 +08:00
sb_target.SetSP (target_sp);
}
First pass at adding logging capabilities for the API functions. At the moment it logs the function calls, their arguments and the return values. This is not complete or polished, but I am committing it now, at the request of someone who really wants to use it, even though it's not really done. It currently does not attempt to log all the functions, just the most important ones. I will be making further adjustments to the API logging code over the next few days/weeks. (Suggestions for improvements are welcome). Update the Python build scripts to re-build the swig C++ file whenever the python-extensions.swig file is modified. Correct the help for 'log enable' command (give it the correct number & type of arguments). llvm-svn: 117349
2010-10-26 11:11:13 +08:00
if (log)
lldb::SBTarget and lldb::SBProcess are now thread hardened. They both still contain shared pointers to the lldb_private::Target and lldb_private::Process objects respectively as we won't want the target or process just going away. Also cleaned up the lldb::SBModule to remove dangerous pointer accessors. For any code the public API files, we should always be grabbing shared pointers to any objects for the current class, and any other classes prior to running code with them. llvm-svn: 149238
2012-01-30 17:04:36 +08:00
log->Printf ("SBProcess(%p)::GetTarget () => SBTarget(%p)", process_sp.get(), target_sp.get());
First pass at adding logging capabilities for the API functions. At the moment it logs the function calls, their arguments and the return values. This is not complete or polished, but I am committing it now, at the request of someone who really wants to use it, even though it's not really done. It currently does not attempt to log all the functions, just the most important ones. I will be making further adjustments to the API logging code over the next few days/weeks. (Suggestions for improvements are welcome). Update the Python build scripts to re-build the swig C++ file whenever the python-extensions.swig file is modified. Correct the help for 'log enable' command (give it the correct number & type of arguments). llvm-svn: 117349
2010-10-26 11:11:13 +08:00
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
return sb_target;
}
size_t
SBProcess::PutSTDIN (const char *src, size_t src_len)
{
<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_API));
First pass at adding logging capabilities for the API functions. At the moment it logs the function calls, their arguments and the return values. This is not complete or polished, but I am committing it now, at the request of someone who really wants to use it, even though it's not really done. It currently does not attempt to log all the functions, just the most important ones. I will be making further adjustments to the API logging code over the next few days/weeks. (Suggestions for improvements are welcome). Update the Python build scripts to re-build the swig C++ file whenever the python-extensions.swig file is modified. Correct the help for 'log enable' command (give it the correct number & type of arguments). llvm-svn: 117349
2010-10-26 11:11:13 +08:00
size_t ret_val = 0;
lldb::SBTarget and lldb::SBProcess are now thread hardened. They both still contain shared pointers to the lldb_private::Target and lldb_private::Process objects respectively as we won't want the target or process just going away. Also cleaned up the lldb::SBModule to remove dangerous pointer accessors. For any code the public API files, we should always be grabbing shared pointers to any objects for the current class, and any other classes prior to running code with them. llvm-svn: 149238
2012-01-30 17:04:36 +08:00
ProcessSP process_sp(GetSP());
if (process_sp)
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
{
Error error;
lldb::SBTarget and lldb::SBProcess are now thread hardened. They both still contain shared pointers to the lldb_private::Target and lldb_private::Process objects respectively as we won't want the target or process just going away. Also cleaned up the lldb::SBModule to remove dangerous pointer accessors. For any code the public API files, we should always be grabbing shared pointers to any objects for the current class, and any other classes prior to running code with them. llvm-svn: 149238
2012-01-30 17:04:36 +08:00
ret_val = process_sp->PutSTDIN (src, src_len, error);
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
First pass at adding logging capabilities for the API functions. At the moment it logs the function calls, their arguments and the return values. This is not complete or polished, but I am committing it now, at the request of someone who really wants to use it, even though it's not really done. It currently does not attempt to log all the functions, just the most important ones. I will be making further adjustments to the API logging code over the next few days/weeks. (Suggestions for improvements are welcome). Update the Python build scripts to re-build the swig C++ file whenever the python-extensions.swig file is modified. Correct the help for 'log enable' command (give it the correct number & type of arguments). llvm-svn: 117349
2010-10-26 11:11:13 +08:00
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 ("SBProcess(%p)::PutSTDIN (src=\"%s\", src_len=%d) => %lu",
lldb::SBTarget and lldb::SBProcess are now thread hardened. They both still contain shared pointers to the lldb_private::Target and lldb_private::Process objects respectively as we won't want the target or process just going away. Also cleaned up the lldb::SBModule to remove dangerous pointer accessors. For any code the public API files, we should always be grabbing shared pointers to any objects for the current class, and any other classes prior to running code with them. llvm-svn: 149238
2012-01-30 17:04:36 +08:00
process_sp.get(),
Modified the lldb_private::TypeList to use a std::multimap for quicker lookup by type ID (the most common type of type lookup). Changed the API logging a bit to always show the objects in the OBJECT(POINTER) format so it will be easy to locate all instances of an object or references to it when looking at logs. llvm-svn: 117641
2010-10-29 12:59:35 +08:00
src,
(uint32_t) src_len,
ret_val);
First pass at adding logging capabilities for the API functions. At the moment it logs the function calls, their arguments and the return values. This is not complete or polished, but I am committing it now, at the request of someone who really wants to use it, even though it's not really done. It currently does not attempt to log all the functions, just the most important ones. I will be making further adjustments to the API logging code over the next few days/weeks. (Suggestions for improvements are welcome). Update the Python build scripts to re-build the swig C++ file whenever the python-extensions.swig file is modified. Correct the help for 'log enable' command (give it the correct number & type of arguments). llvm-svn: 117349
2010-10-26 11:11:13 +08:00
return ret_val;
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
size_t
SBProcess::GetSTDOUT (char *dst, size_t dst_len) const
{
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
size_t bytes_read = 0;
lldb::SBTarget and lldb::SBProcess are now thread hardened. They both still contain shared pointers to the lldb_private::Target and lldb_private::Process objects respectively as we won't want the target or process just going away. Also cleaned up the lldb::SBModule to remove dangerous pointer accessors. For any code the public API files, we should always be grabbing shared pointers to any objects for the current class, and any other classes prior to running code with them. llvm-svn: 149238
2012-01-30 17:04:36 +08:00
ProcessSP process_sp(GetSP());
if (process_sp)
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
{
Error error;
lldb::SBTarget and lldb::SBProcess are now thread hardened. They both still contain shared pointers to the lldb_private::Target and lldb_private::Process objects respectively as we won't want the target or process just going away. Also cleaned up the lldb::SBModule to remove dangerous pointer accessors. For any code the public API files, we should always be grabbing shared pointers to any objects for the current class, and any other classes prior to running code with them. llvm-svn: 149238
2012-01-30 17:04:36 +08:00
bytes_read = process_sp->GetSTDOUT (dst, dst_len, error);
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
First pass at adding logging capabilities for the API functions. At the moment it logs the function calls, their arguments and the return values. This is not complete or polished, but I am committing it now, at the request of someone who really wants to use it, even though it's not really done. It currently does not attempt to log all the functions, just the most important ones. I will be making further adjustments to the API logging code over the next few days/weeks. (Suggestions for improvements are welcome). Update the Python build scripts to re-build the swig C++ file whenever the python-extensions.swig file is modified. Correct the help for 'log enable' command (give it the correct number & type of arguments). llvm-svn: 117349
2010-10-26 11:11:13 +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_API));
First pass at adding logging capabilities for the API functions. At the moment it logs the function calls, their arguments and the return values. This is not complete or polished, but I am committing it now, at the request of someone who really wants to use it, even though it's not really done. It currently does not attempt to log all the functions, just the most important ones. I will be making further adjustments to the API logging code over the next few days/weeks. (Suggestions for improvements are welcome). Update the Python build scripts to re-build the swig C++ file whenever the python-extensions.swig file is modified. Correct the help for 'log enable' command (give it the correct number & type of arguments). llvm-svn: 117349
2010-10-26 11:11:13 +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 ("SBProcess(%p)::GetSTDOUT (dst=\"%.*s\", dst_len=%" PRIu64 ") => %" PRIu64,
Stop using the "%z" size_t modifier and cast all size_t values to uint64_t. Some platforms don't support this modification. llvm-svn: 164148
2012-09-19 02:04:04 +08:00
process_sp.get(),
(int) bytes_read,
dst,
(uint64_t)dst_len,
(uint64_t)bytes_read);
First pass at adding logging capabilities for the API functions. At the moment it logs the function calls, their arguments and the return values. This is not complete or polished, but I am committing it now, at the request of someone who really wants to use it, even though it's not really done. It currently does not attempt to log all the functions, just the most important ones. I will be making further adjustments to the API logging code over the next few days/weeks. (Suggestions for improvements are welcome). Update the Python build scripts to re-build the swig C++ file whenever the python-extensions.swig file is modified. Correct the help for 'log enable' command (give it the correct number & type of arguments). llvm-svn: 117349
2010-10-26 11:11:13 +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
return bytes_read;
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
size_t
SBProcess::GetSTDERR (char *dst, size_t dst_len) const
{
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
size_t bytes_read = 0;
lldb::SBTarget and lldb::SBProcess are now thread hardened. They both still contain shared pointers to the lldb_private::Target and lldb_private::Process objects respectively as we won't want the target or process just going away. Also cleaned up the lldb::SBModule to remove dangerous pointer accessors. For any code the public API files, we should always be grabbing shared pointers to any objects for the current class, and any other classes prior to running code with them. llvm-svn: 149238
2012-01-30 17:04:36 +08:00
ProcessSP process_sp(GetSP());
if (process_sp)
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
{
Error error;
lldb::SBTarget and lldb::SBProcess are now thread hardened. They both still contain shared pointers to the lldb_private::Target and lldb_private::Process objects respectively as we won't want the target or process just going away. Also cleaned up the lldb::SBModule to remove dangerous pointer accessors. For any code the public API files, we should always be grabbing shared pointers to any objects for the current class, and any other classes prior to running code with them. llvm-svn: 149238
2012-01-30 17:04:36 +08:00
bytes_read = process_sp->GetSTDERR (dst, dst_len, error);
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
First pass at adding logging capabilities for the API functions. At the moment it logs the function calls, their arguments and the return values. This is not complete or polished, but I am committing it now, at the request of someone who really wants to use it, even though it's not really done. It currently does not attempt to log all the functions, just the most important ones. I will be making further adjustments to the API logging code over the next few days/weeks. (Suggestions for improvements are welcome). Update the Python build scripts to re-build the swig C++ file whenever the python-extensions.swig file is modified. Correct the help for 'log enable' command (give it the correct number & type of arguments). llvm-svn: 117349
2010-10-26 11:11:13 +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_API));
First pass at adding logging capabilities for the API functions. At the moment it logs the function calls, their arguments and the return values. This is not complete or polished, but I am committing it now, at the request of someone who really wants to use it, even though it's not really done. It currently does not attempt to log all the functions, just the most important ones. I will be making further adjustments to the API logging code over the next few days/weeks. (Suggestions for improvements are welcome). Update the Python build scripts to re-build the swig C++ file whenever the python-extensions.swig file is modified. Correct the help for 'log enable' command (give it the correct number & type of arguments). llvm-svn: 117349
2010-10-26 11:11:13 +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 ("SBProcess(%p)::GetSTDERR (dst=\"%.*s\", dst_len=%" PRIu64 ") => %" PRIu64,
Stop using the "%z" size_t modifier and cast all size_t values to uint64_t. Some platforms don't support this modification. llvm-svn: 164148
2012-09-19 02:04:04 +08:00
process_sp.get(),
(int) bytes_read,
dst,
(uint64_t)dst_len,
(uint64_t)bytes_read);
First pass at adding logging capabilities for the API functions. At the moment it logs the function calls, their arguments and the return values. This is not complete or polished, but I am committing it now, at the request of someone who really wants to use it, even though it's not really done. It currently does not attempt to log all the functions, just the most important ones. I will be making further adjustments to the API logging code over the next few days/weeks. (Suggestions for improvements are welcome). Update the Python build scripts to re-build the swig C++ file whenever the python-extensions.swig file is modified. Correct the help for 'log enable' command (give it the correct number & type of arguments). llvm-svn: 117349
2010-10-26 11:11:13 +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
return bytes_read;
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +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
size_t
SBProcess::GetAsyncProfileData(char *dst, size_t dst_len) const
{
size_t bytes_read = 0;
ProcessSP process_sp(GetSP());
if (process_sp)
{
Error error;
bytes_read = process_sp->GetAsyncProfileData (dst, dst_len, 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_API));
<rdar://problem/12720514> Sub-TLF: Provide service to profile the inferior This allows client to query profiling states on the inferior. llvm-svn: 168228
2012-11-17 08:21:04 +08:00
if (log)
Resolve printf formatting warnings on Linux: - use macros from inttypes.h for format strings instead of OS-specific types Patch from Matt Kopec! llvm-svn: 168945
2012-11-30 05:49:15 +08:00
log->Printf ("SBProcess(%p)::GetProfileData (dst=\"%.*s\", dst_len=%" PRIu64 ") => %" PRIu64,
<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
process_sp.get(),
(int) bytes_read,
dst,
(uint64_t)dst_len,
(uint64_t)bytes_read);
return bytes_read;
}
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
void
Change "Current" as in GetCurrentThread, GetCurrentStackFrame, etc, to "Selected" i.e. GetSelectedThread. Selected makes more sense, since these are set by some user action (a selection). I didn't change "CurrentProcess" since this is always controlled by the target, and a given target can only have one process, so it really can't be selected. llvm-svn: 112221
2010-08-27 05:32:51 +08:00
SBProcess::ReportEventState (const SBEvent &event, FILE *out) const
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
{
if (out == NULL)
return;
lldb::SBTarget and lldb::SBProcess are now thread hardened. They both still contain shared pointers to the lldb_private::Target and lldb_private::Process objects respectively as we won't want the target or process just going away. Also cleaned up the lldb::SBModule to remove dangerous pointer accessors. For any code the public API files, we should always be grabbing shared pointers to any objects for the current class, and any other classes prior to running code with them. llvm-svn: 149238
2012-01-30 17:04:36 +08:00
ProcessSP process_sp(GetSP());
if (process_sp)
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
{
const StateType event_state = SBProcess::GetStateFromEvent (event);
char message[1024];
int message_len = ::snprintf (message,
sizeof (message),
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
"Process %" PRIu64 " %s\n",
lldb::SBTarget and lldb::SBProcess are now thread hardened. They both still contain shared pointers to the lldb_private::Target and lldb_private::Process objects respectively as we won't want the target or process just going away. Also cleaned up the lldb::SBModule to remove dangerous pointer accessors. For any code the public API files, we should always be grabbing shared pointers to any objects for the current class, and any other classes prior to running code with them. llvm-svn: 149238
2012-01-30 17:04:36 +08:00
process_sp->GetID(),
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
SBDebugger::StateAsCString (event_state));
if (message_len > 0)
::fwrite (message, 1, message_len, out);
}
}
void
Change "Current" as in GetCurrentThread, GetCurrentStackFrame, etc, to "Selected" i.e. GetSelectedThread. Selected makes more sense, since these are set by some user action (a selection). I didn't change "CurrentProcess" since this is always controlled by the target, and a given target can only have one process, so it really can't be selected. llvm-svn: 112221
2010-08-27 05:32:51 +08:00
SBProcess::AppendEventStateReport (const SBEvent &event, SBCommandReturnObject &result)
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
{
lldb::SBTarget and lldb::SBProcess are now thread hardened. They both still contain shared pointers to the lldb_private::Target and lldb_private::Process objects respectively as we won't want the target or process just going away. Also cleaned up the lldb::SBModule to remove dangerous pointer accessors. For any code the public API files, we should always be grabbing shared pointers to any objects for the current class, and any other classes prior to running code with them. llvm-svn: 149238
2012-01-30 17:04:36 +08:00
ProcessSP process_sp(GetSP());
if (process_sp)
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
{
const StateType event_state = SBProcess::GetStateFromEvent (event);
char message[1024];
::snprintf (message,
sizeof (message),
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
"Process %" PRIu64 " %s\n",
lldb::SBTarget and lldb::SBProcess are now thread hardened. They both still contain shared pointers to the lldb_private::Target and lldb_private::Process objects respectively as we won't want the target or process just going away. Also cleaned up the lldb::SBModule to remove dangerous pointer accessors. For any code the public API files, we should always be grabbing shared pointers to any objects for the current class, and any other classes prior to running code with them. llvm-svn: 149238
2012-01-30 17:04:36 +08:00
process_sp->GetID(),
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
SBDebugger::StateAsCString (event_state));
result.AppendMessage (message);
}
}
bool
Change "Current" as in GetCurrentThread, GetCurrentStackFrame, etc, to "Selected" i.e. GetSelectedThread. Selected makes more sense, since these are set by some user action (a selection). I didn't change "CurrentProcess" since this is always controlled by the target, and a given target can only have one process, so it really can't be selected. llvm-svn: 112221
2010-08-27 05:32:51 +08:00
SBProcess::SetSelectedThread (const SBThread &thread)
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
{
lldb::SBTarget and lldb::SBProcess are now thread hardened. They both still contain shared pointers to the lldb_private::Target and lldb_private::Process objects respectively as we won't want the target or process just going away. Also cleaned up the lldb::SBModule to remove dangerous pointer accessors. For any code the public API files, we should always be grabbing shared pointers to any objects for the current class, and any other classes prior to running code with them. llvm-svn: 149238
2012-01-30 17:04:36 +08:00
ProcessSP process_sp(GetSP());
if (process_sp)
The LLDB API (lldb::SB*) is now thread safe! llvm-svn: 122262
2010-12-21 04:49:23 +08:00
{
lldb::SBTarget and lldb::SBProcess are now thread hardened. They both still contain shared pointers to the lldb_private::Target and lldb_private::Process objects respectively as we won't want the target or process just going away. Also cleaned up the lldb::SBModule to remove dangerous pointer accessors. For any code the public API files, we should always be grabbing shared pointers to any objects for the current class, and any other classes prior to running code with them. llvm-svn: 149238
2012-01-30 17:04:36 +08:00
Mutex::Locker api_locker (process_sp->GetTarget().GetAPIMutex());
return process_sp->GetThreadList().SetSelectedThreadByID (thread.GetThreadID());
The LLDB API (lldb::SB*) is now thread safe! llvm-svn: 122262
2010-12-21 04:49:23 +08:00
}
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
return false;
}
<rdar://problem/12490558> SBProcess::SetSelectedThreadByID() had a "uint32_t tid" parameter which would truncate 64 bit thread IDs (lldb::tid_t is 64 bit). llvm-svn: 165852
2012-10-13 07:32:11 +08:00
bool
SBProcess::SetSelectedThreadByID (lldb::tid_t tid)
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_API));
First pass at adding logging capabilities for the API functions. At the moment it logs the function calls, their arguments and the return values. This is not complete or polished, but I am committing it now, at the request of someone who really wants to use it, even though it's not really done. It currently does not attempt to log all the functions, just the most important ones. I will be making further adjustments to the API logging code over the next few days/weeks. (Suggestions for improvements are welcome). Update the Python build scripts to re-build the swig C++ file whenever the python-extensions.swig file is modified. Correct the help for 'log enable' command (give it the correct number & type of arguments). llvm-svn: 117349
2010-10-26 11:11:13 +08:00
bool ret_val = false;
lldb::SBTarget and lldb::SBProcess are now thread hardened. They both still contain shared pointers to the lldb_private::Target and lldb_private::Process objects respectively as we won't want the target or process just going away. Also cleaned up the lldb::SBModule to remove dangerous pointer accessors. For any code the public API files, we should always be grabbing shared pointers to any objects for the current class, and any other classes prior to running code with them. llvm-svn: 149238
2012-01-30 17:04:36 +08:00
ProcessSP process_sp(GetSP());
if (process_sp)
The LLDB API (lldb::SB*) is now thread safe! llvm-svn: 122262
2010-12-21 04:49:23 +08:00
{
lldb::SBTarget and lldb::SBProcess are now thread hardened. They both still contain shared pointers to the lldb_private::Target and lldb_private::Process objects respectively as we won't want the target or process just going away. Also cleaned up the lldb::SBModule to remove dangerous pointer accessors. For any code the public API files, we should always be grabbing shared pointers to any objects for the current class, and any other classes prior to running code with them. llvm-svn: 149238
2012-01-30 17:04:36 +08:00
Mutex::Locker api_locker (process_sp->GetTarget().GetAPIMutex());
ret_val = process_sp->GetThreadList().SetSelectedThreadByID (tid);
The LLDB API (lldb::SB*) is now thread safe! llvm-svn: 122262
2010-12-21 04:49:23 +08:00
}
First pass at adding logging capabilities for the API functions. At the moment it logs the function calls, their arguments and the return values. This is not complete or polished, but I am committing it now, at the request of someone who really wants to use it, even though it's not really done. It currently does not attempt to log all the functions, just the most important ones. I will be making further adjustments to the API logging code over the next few days/weeks. (Suggestions for improvements are welcome). Update the Python build scripts to re-build the swig C++ file whenever the python-extensions.swig file is modified. Correct the help for 'log enable' command (give it the correct number & type of arguments). llvm-svn: 117349
2010-10-26 11:11:13 +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 ("SBProcess(%p)::SetSelectedThreadByID (tid=0x%4.4" PRIx64 ") => %s",
lldb::SBTarget and lldb::SBProcess are now thread hardened. They both still contain shared pointers to the lldb_private::Target and lldb_private::Process objects respectively as we won't want the target or process just going away. Also cleaned up the lldb::SBModule to remove dangerous pointer accessors. For any code the public API files, we should always be grabbing shared pointers to any objects for the current class, and any other classes prior to running code with them. llvm-svn: 149238
2012-01-30 17:04:36 +08:00
process_sp.get(), tid, (ret_val ? "true" : "false"));
First pass at adding logging capabilities for the API functions. At the moment it logs the function calls, their arguments and the return values. This is not complete or polished, but I am committing it now, at the request of someone who really wants to use it, even though it's not really done. It currently does not attempt to log all the functions, just the most important ones. I will be making further adjustments to the API logging code over the next few days/weeks. (Suggestions for improvements are welcome). Update the Python build scripts to re-build the swig C++ file whenever the python-extensions.swig file is modified. Correct the help for 'log enable' command (give it the correct number & type of arguments). llvm-svn: 117349
2010-10-26 11:11:13 +08:00
return ret_val;
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
Add accessors on process to get & set the selected thread by IndexID (useful since that's the one that "thread list" shows and it won't get reused even if the underlying system thread ID gets reused. llvm-svn: 160187
2012-07-14 04:18:18 +08:00
bool
SBProcess::SetSelectedThreadByIndexID (uint32_t index_id)
{
<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_API));
Add accessors on process to get & set the selected thread by IndexID (useful since that's the one that "thread list" shows and it won't get reused even if the underlying system thread ID gets reused. llvm-svn: 160187
2012-07-14 04:18:18 +08:00
bool ret_val = false;
ProcessSP process_sp(GetSP());
if (process_sp)
{
Mutex::Locker api_locker (process_sp->GetTarget().GetAPIMutex());
ret_val = process_sp->GetThreadList().SetSelectedThreadByIndexID (index_id);
}
if (log)
log->Printf ("SBProcess(%p)::SetSelectedThreadByID (tid=0x%x) => %s",
process_sp.get(), index_id, (ret_val ? "true" : "false"));
return ret_val;
}
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
SBThread
SBProcess::GetThreadAtIndex (size_t index)
{
<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_API));
First pass at adding logging capabilities for the API functions. At the moment it logs the function calls, their arguments and the return values. This is not complete or polished, but I am committing it now, at the request of someone who really wants to use it, even though it's not really done. It currently does not attempt to log all the functions, just the most important ones. I will be making further adjustments to the API logging code over the next few days/weeks. (Suggestions for improvements are welcome). Update the Python build scripts to re-build the swig C++ file whenever the python-extensions.swig file is modified. Correct the help for 'log enable' command (give it the correct number & type of arguments). llvm-svn: 117349
2010-10-26 11:11:13 +08:00
Removed the "lldb-forward-rtti.h" header file as it was designed to contain all RTTI types, and since we don't use RTTI anymore since clang and llvm don't we don't really need this header file. All shared pointer definitions have been moved into "lldb-forward.h". Defined std::tr1::weak_ptr definitions for all of the types that inherit from enable_shared_from_this() in "lldb-forward.h" in preparation for thread hardening our public API. The first in the thread hardening check-ins. First we start with SBThread. We have issues in our lldb::SB API right now where if you have one object that is being used by two threads we have a race condition. Consider the following code: 1 int 2 SBThread::SomeFunction() 3 { 4 int result = -1; 5 if (m_opaque_sp) 6 { 7 result = m_opaque_sp->DoSomething(); 8 } 9 return result; 10 } And now this happens: Thread 1 enters any SBThread function and checks its m_opaque_sp and is about to execute the code on line 7 but hasn't yet Thread 2 gets to run and class sb_thread.Clear() which calls m_opaque_sp.clear() and clears the contents of the shared pointer member Thread 1 now crashes when it resumes. The solution is to use std::tr1::weak_ptr. Now the SBThread class contains a lldb::ThreadWP (weak pointer to our lldb_private::Thread class) and this function would look like: 1 int 2 SBThread::SomeFunction() 3 { 4 int result = -1; 5 ThreadSP thread_sp(m_opaque_wp.lock()); 6 if (thread_sp) 7 { 8 result = m_opaque_sp->DoSomething(); 9 } 10 return result; 11 } Now we have a solid thread safe API where we get a local copy of our thread shared pointer from our weak_ptr and then we are guaranteed it can't go away during our function. So lldb::SBThread has been thread hardened, more checkins to follow shortly. llvm-svn: 149218
2012-01-30 10:53:15 +08:00
SBThread sb_thread;
ThreadSP thread_sp;
lldb::SBTarget and lldb::SBProcess are now thread hardened. They both still contain shared pointers to the lldb_private::Target and lldb_private::Process objects respectively as we won't want the target or process just going away. Also cleaned up the lldb::SBModule to remove dangerous pointer accessors. For any code the public API files, we should always be grabbing shared pointers to any objects for the current class, and any other classes prior to running code with them. llvm-svn: 149238
2012-01-30 17:04:36 +08:00
ProcessSP process_sp(GetSP());
if (process_sp)
The LLDB API (lldb::SB*) is now thread safe! llvm-svn: 122262
2010-12-21 04:49:23 +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
Process::StopLocker stop_locker;
const bool can_update = stop_locker.TryLock(&process_sp->GetRunLock());
lldb::SBTarget and lldb::SBProcess are now thread hardened. They both still contain shared pointers to the lldb_private::Target and lldb_private::Process objects respectively as we won't want the target or process just going away. Also cleaned up the lldb::SBModule to remove dangerous pointer accessors. For any code the public API files, we should always be grabbing shared pointers to any objects for the current class, and any other classes prior to running code with them. llvm-svn: 149238
2012-01-30 17:04:36 +08:00
Mutex::Locker api_locker (process_sp->GetTarget().GetAPIMutex());
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
thread_sp = process_sp->GetThreadList().GetThreadAtIndex(index, can_update);
Removed the "lldb-forward-rtti.h" header file as it was designed to contain all RTTI types, and since we don't use RTTI anymore since clang and llvm don't we don't really need this header file. All shared pointer definitions have been moved into "lldb-forward.h". Defined std::tr1::weak_ptr definitions for all of the types that inherit from enable_shared_from_this() in "lldb-forward.h" in preparation for thread hardening our public API. The first in the thread hardening check-ins. First we start with SBThread. We have issues in our lldb::SB API right now where if you have one object that is being used by two threads we have a race condition. Consider the following code: 1 int 2 SBThread::SomeFunction() 3 { 4 int result = -1; 5 if (m_opaque_sp) 6 { 7 result = m_opaque_sp->DoSomething(); 8 } 9 return result; 10 } And now this happens: Thread 1 enters any SBThread function and checks its m_opaque_sp and is about to execute the code on line 7 but hasn't yet Thread 2 gets to run and class sb_thread.Clear() which calls m_opaque_sp.clear() and clears the contents of the shared pointer member Thread 1 now crashes when it resumes. The solution is to use std::tr1::weak_ptr. Now the SBThread class contains a lldb::ThreadWP (weak pointer to our lldb_private::Thread class) and this function would look like: 1 int 2 SBThread::SomeFunction() 3 { 4 int result = -1; 5 ThreadSP thread_sp(m_opaque_wp.lock()); 6 if (thread_sp) 7 { 8 result = m_opaque_sp->DoSomething(); 9 } 10 return result; 11 } Now we have a solid thread safe API where we get a local copy of our thread shared pointer from our weak_ptr and then we are guaranteed it can't go away during our function. So lldb::SBThread has been thread hardened, more checkins to follow shortly. llvm-svn: 149218
2012-01-30 10:53:15 +08:00
sb_thread.SetThread (thread_sp);
The LLDB API (lldb::SB*) is now thread safe! llvm-svn: 122262
2010-12-21 04:49:23 +08:00
}
First pass at adding logging capabilities for the API functions. At the moment it logs the function calls, their arguments and the return values. This is not complete or polished, but I am committing it now, at the request of someone who really wants to use it, even though it's not really done. It currently does not attempt to log all the functions, just the most important ones. I will be making further adjustments to the API logging code over the next few days/weeks. (Suggestions for improvements are welcome). Update the Python build scripts to re-build the swig C++ file whenever the python-extensions.swig file is modified. Correct the help for 'log enable' command (give it the correct number & type of arguments). llvm-svn: 117349
2010-10-26 11:11:13 +08:00
if (log)
{
Modified the lldb_private::TypeList to use a std::multimap for quicker lookup by type ID (the most common type of type lookup). Changed the API logging a bit to always show the objects in the OBJECT(POINTER) format so it will be easy to locate all instances of an object or references to it when looking at logs. llvm-svn: 117641
2010-10-29 12:59:35 +08:00
log->Printf ("SBProcess(%p)::GetThreadAtIndex (index=%d) => SBThread(%p)",
lldb::SBTarget and lldb::SBProcess are now thread hardened. They both still contain shared pointers to the lldb_private::Target and lldb_private::Process objects respectively as we won't want the target or process just going away. Also cleaned up the lldb::SBModule to remove dangerous pointer accessors. For any code the public API files, we should always be grabbing shared pointers to any objects for the current class, and any other classes prior to running code with them. llvm-svn: 149238
2012-01-30 17:04:36 +08:00
process_sp.get(), (uint32_t) index, thread_sp.get());
First pass at adding logging capabilities for the API functions. At the moment it logs the function calls, their arguments and the return values. This is not complete or polished, but I am committing it now, at the request of someone who really wants to use it, even though it's not really done. It currently does not attempt to log all the functions, just the most important ones. I will be making further adjustments to the API logging code over the next few days/weeks. (Suggestions for improvements are welcome). Update the Python build scripts to re-build the swig C++ file whenever the python-extensions.swig file is modified. Correct the help for 'log enable' command (give it the correct number & type of arguments). llvm-svn: 117349
2010-10-26 11:11:13 +08:00
}
Removed the "lldb-forward-rtti.h" header file as it was designed to contain all RTTI types, and since we don't use RTTI anymore since clang and llvm don't we don't really need this header file. All shared pointer definitions have been moved into "lldb-forward.h". Defined std::tr1::weak_ptr definitions for all of the types that inherit from enable_shared_from_this() in "lldb-forward.h" in preparation for thread hardening our public API. The first in the thread hardening check-ins. First we start with SBThread. We have issues in our lldb::SB API right now where if you have one object that is being used by two threads we have a race condition. Consider the following code: 1 int 2 SBThread::SomeFunction() 3 { 4 int result = -1; 5 if (m_opaque_sp) 6 { 7 result = m_opaque_sp->DoSomething(); 8 } 9 return result; 10 } And now this happens: Thread 1 enters any SBThread function and checks its m_opaque_sp and is about to execute the code on line 7 but hasn't yet Thread 2 gets to run and class sb_thread.Clear() which calls m_opaque_sp.clear() and clears the contents of the shared pointer member Thread 1 now crashes when it resumes. The solution is to use std::tr1::weak_ptr. Now the SBThread class contains a lldb::ThreadWP (weak pointer to our lldb_private::Thread class) and this function would look like: 1 int 2 SBThread::SomeFunction() 3 { 4 int result = -1; 5 ThreadSP thread_sp(m_opaque_wp.lock()); 6 if (thread_sp) 7 { 8 result = m_opaque_sp->DoSomething(); 9 } 10 return result; 11 } Now we have a solid thread safe API where we get a local copy of our thread shared pointer from our weak_ptr and then we are guaranteed it can't go away during our function. So lldb::SBThread has been thread hardened, more checkins to follow shortly. llvm-svn: 149218
2012-01-30 10:53:15 +08:00
return sb_thread;
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
Add an SBProcess API to get the current StopID, either considering or ignoring stops caused by expression evaluation. <rdar://problem/12968562> llvm-svn: 171914
2013-01-09 07:22:42 +08:00
uint32_t
SBProcess::GetStopID(bool include_expression_stops)
{
ProcessSP process_sp(GetSP());
if (process_sp)
{
Mutex::Locker api_locker (process_sp->GetTarget().GetAPIMutex());
if (include_expression_stops)
return process_sp->GetStopID();
else
return process_sp->GetLastNaturalStopID();
}
return 0;
}
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
StateType
SBProcess::GetState ()
{
First pass at adding logging capabilities for the API functions. At the moment it logs the function calls, their arguments and the return values. This is not complete or polished, but I am committing it now, at the request of someone who really wants to use it, even though it's not really done. It currently does not attempt to log all the functions, just the most important ones. I will be making further adjustments to the API logging code over the next few days/weeks. (Suggestions for improvements are welcome). Update the Python build scripts to re-build the swig C++ file whenever the python-extensions.swig file is modified. Correct the help for 'log enable' command (give it the correct number & type of arguments). llvm-svn: 117349
2010-10-26 11:11:13 +08:00
StateType ret_val = eStateInvalid;
lldb::SBTarget and lldb::SBProcess are now thread hardened. They both still contain shared pointers to the lldb_private::Target and lldb_private::Process objects respectively as we won't want the target or process just going away. Also cleaned up the lldb::SBModule to remove dangerous pointer accessors. For any code the public API files, we should always be grabbing shared pointers to any objects for the current class, and any other classes prior to running code with them. llvm-svn: 149238
2012-01-30 17:04:36 +08:00
ProcessSP process_sp(GetSP());
if (process_sp)
The LLDB API (lldb::SB*) is now thread safe! llvm-svn: 122262
2010-12-21 04:49:23 +08:00
{
lldb::SBTarget and lldb::SBProcess are now thread hardened. They both still contain shared pointers to the lldb_private::Target and lldb_private::Process objects respectively as we won't want the target or process just going away. Also cleaned up the lldb::SBModule to remove dangerous pointer accessors. For any code the public API files, we should always be grabbing shared pointers to any objects for the current class, and any other classes prior to running code with them. llvm-svn: 149238
2012-01-30 17:04:36 +08:00
Mutex::Locker api_locker (process_sp->GetTarget().GetAPIMutex());
ret_val = process_sp->GetState();
The LLDB API (lldb::SB*) is now thread safe! llvm-svn: 122262
2010-12-21 04:49:23 +08:00
}
First pass at adding logging capabilities for the API functions. At the moment it logs the function calls, their arguments and the return values. This is not complete or polished, but I am committing it now, at the request of someone who really wants to use it, even though it's not really done. It currently does not attempt to log all the functions, just the most important ones. I will be making further adjustments to the API logging code over the next few days/weeks. (Suggestions for improvements are welcome). Update the Python build scripts to re-build the swig C++ file whenever the python-extensions.swig file is modified. Correct the help for 'log enable' command (give it the correct number & type of arguments). llvm-svn: 117349
2010-10-26 11:11:13 +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_API));
First pass at adding logging capabilities for the API functions. At the moment it logs the function calls, their arguments and the return values. This is not complete or polished, but I am committing it now, at the request of someone who really wants to use it, even though it's not really done. It currently does not attempt to log all the functions, just the most important ones. I will be making further adjustments to the API logging code over the next few days/weeks. (Suggestions for improvements are welcome). Update the Python build scripts to re-build the swig C++ file whenever the python-extensions.swig file is modified. Correct the help for 'log enable' command (give it the correct number & type of arguments). llvm-svn: 117349
2010-10-26 11:11:13 +08:00
if (log)
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
log->Printf ("SBProcess(%p)::GetState () => %s",
lldb::SBTarget and lldb::SBProcess are now thread hardened. They both still contain shared pointers to the lldb_private::Target and lldb_private::Process objects respectively as we won't want the target or process just going away. Also cleaned up the lldb::SBModule to remove dangerous pointer accessors. For any code the public API files, we should always be grabbing shared pointers to any objects for the current class, and any other classes prior to running code with them. llvm-svn: 149238
2012-01-30 17:04:36 +08:00
process_sp.get(),
Clean up the API logging code: - Try to reduce logging to one line per function call instead of tw - Put all arguments & their values into log for calls - Add 'this' parameter information to function call logging, making it show the appropriate internal pointer (this.obj, this.sp, this.ap...) - Clean up some return values - Remove logging of constructors that construct empty objects - Change '==>' to '=>' for showing result values... - Fix various minor bugs - Add some protected 'get' functions to help getting the internal pointers for the 'this' arguments... llvm-svn: 117417
2010-10-27 07:49:36 +08:00
lldb_private::StateAsCString (ret_val));
First pass at adding logging capabilities for the API functions. At the moment it logs the function calls, their arguments and the return values. This is not complete or polished, but I am committing it now, at the request of someone who really wants to use it, even though it's not really done. It currently does not attempt to log all the functions, just the most important ones. I will be making further adjustments to the API logging code over the next few days/weeks. (Suggestions for improvements are welcome). Update the Python build scripts to re-build the swig C++ file whenever the python-extensions.swig file is modified. Correct the help for 'log enable' command (give it the correct number & type of arguments). llvm-svn: 117349
2010-10-26 11:11:13 +08:00
return ret_val;
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
int
SBProcess::GetExitStatus ()
{
Improved API logging. llvm-svn: 117772
2010-10-30 12:51:46 +08:00
int exit_status = 0;
lldb::SBTarget and lldb::SBProcess are now thread hardened. They both still contain shared pointers to the lldb_private::Target and lldb_private::Process objects respectively as we won't want the target or process just going away. Also cleaned up the lldb::SBModule to remove dangerous pointer accessors. For any code the public API files, we should always be grabbing shared pointers to any objects for the current class, and any other classes prior to running code with them. llvm-svn: 149238
2012-01-30 17:04:36 +08:00
ProcessSP process_sp(GetSP());
if (process_sp)
The LLDB API (lldb::SB*) is now thread safe! llvm-svn: 122262
2010-12-21 04:49:23 +08:00
{
lldb::SBTarget and lldb::SBProcess are now thread hardened. They both still contain shared pointers to the lldb_private::Target and lldb_private::Process objects respectively as we won't want the target or process just going away. Also cleaned up the lldb::SBModule to remove dangerous pointer accessors. For any code the public API files, we should always be grabbing shared pointers to any objects for the current class, and any other classes prior to running code with them. llvm-svn: 149238
2012-01-30 17:04:36 +08:00
Mutex::Locker api_locker (process_sp->GetTarget().GetAPIMutex());
exit_status = process_sp->GetExitStatus ();
The LLDB API (lldb::SB*) is now thread safe! llvm-svn: 122262
2010-12-21 04:49:23 +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_API));
Improved API logging. llvm-svn: 117772
2010-10-30 12:51:46 +08:00
if (log)
log->Printf ("SBProcess(%p)::GetExitStatus () => %i (0x%8.8x)",
lldb::SBTarget and lldb::SBProcess are now thread hardened. They both still contain shared pointers to the lldb_private::Target and lldb_private::Process objects respectively as we won't want the target or process just going away. Also cleaned up the lldb::SBModule to remove dangerous pointer accessors. For any code the public API files, we should always be grabbing shared pointers to any objects for the current class, and any other classes prior to running code with them. llvm-svn: 149238
2012-01-30 17:04:36 +08:00
process_sp.get(), exit_status, exit_status);
Improved API logging. llvm-svn: 117772
2010-10-30 12:51:46 +08:00
return exit_status;
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
const char *
SBProcess::GetExitDescription ()
{
Improved API logging. llvm-svn: 117772
2010-10-30 12:51:46 +08:00
const char *exit_desc = NULL;
lldb::SBTarget and lldb::SBProcess are now thread hardened. They both still contain shared pointers to the lldb_private::Target and lldb_private::Process objects respectively as we won't want the target or process just going away. Also cleaned up the lldb::SBModule to remove dangerous pointer accessors. For any code the public API files, we should always be grabbing shared pointers to any objects for the current class, and any other classes prior to running code with them. llvm-svn: 149238
2012-01-30 17:04:36 +08:00
ProcessSP process_sp(GetSP());
if (process_sp)
The LLDB API (lldb::SB*) is now thread safe! llvm-svn: 122262
2010-12-21 04:49:23 +08:00
{
lldb::SBTarget and lldb::SBProcess are now thread hardened. They both still contain shared pointers to the lldb_private::Target and lldb_private::Process objects respectively as we won't want the target or process just going away. Also cleaned up the lldb::SBModule to remove dangerous pointer accessors. For any code the public API files, we should always be grabbing shared pointers to any objects for the current class, and any other classes prior to running code with them. llvm-svn: 149238
2012-01-30 17:04:36 +08:00
Mutex::Locker api_locker (process_sp->GetTarget().GetAPIMutex());
exit_desc = process_sp->GetExitDescription ();
The LLDB API (lldb::SB*) is now thread safe! llvm-svn: 122262
2010-12-21 04:49:23 +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_API));
Improved API logging. llvm-svn: 117772
2010-10-30 12:51:46 +08:00
if (log)
log->Printf ("SBProcess(%p)::GetExitDescription () => %s",
lldb::SBTarget and lldb::SBProcess are now thread hardened. They both still contain shared pointers to the lldb_private::Target and lldb_private::Process objects respectively as we won't want the target or process just going away. Also cleaned up the lldb::SBModule to remove dangerous pointer accessors. For any code the public API files, we should always be grabbing shared pointers to any objects for the current class, and any other classes prior to running code with them. llvm-svn: 149238
2012-01-30 17:04:36 +08:00
process_sp.get(), exit_desc);
Improved API logging. llvm-svn: 117772
2010-10-30 12:51:46 +08:00
return exit_desc;
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
lldb::pid_t
SBProcess::GetProcessID ()
{
First pass at adding logging capabilities for the API functions. At the moment it logs the function calls, their arguments and the return values. This is not complete or polished, but I am committing it now, at the request of someone who really wants to use it, even though it's not really done. It currently does not attempt to log all the functions, just the most important ones. I will be making further adjustments to the API logging code over the next few days/weeks. (Suggestions for improvements are welcome). Update the Python build scripts to re-build the swig C++ file whenever the python-extensions.swig file is modified. Correct the help for 'log enable' command (give it the correct number & type of arguments). llvm-svn: 117349
2010-10-26 11:11:13 +08:00
lldb::pid_t ret_val = LLDB_INVALID_PROCESS_ID;
lldb::SBTarget and lldb::SBProcess are now thread hardened. They both still contain shared pointers to the lldb_private::Target and lldb_private::Process objects respectively as we won't want the target or process just going away. Also cleaned up the lldb::SBModule to remove dangerous pointer accessors. For any code the public API files, we should always be grabbing shared pointers to any objects for the current class, and any other classes prior to running code with them. llvm-svn: 149238
2012-01-30 17:04:36 +08:00
ProcessSP process_sp(GetSP());
if (process_sp)
ret_val = process_sp->GetID();
First pass at adding logging capabilities for the API functions. At the moment it logs the function calls, their arguments and the return values. This is not complete or polished, but I am committing it now, at the request of someone who really wants to use it, even though it's not really done. It currently does not attempt to log all the functions, just the most important ones. I will be making further adjustments to the API logging code over the next few days/weeks. (Suggestions for improvements are welcome). Update the Python build scripts to re-build the swig C++ file whenever the python-extensions.swig file is modified. Correct the help for 'log enable' command (give it the correct number & type of arguments). llvm-svn: 117349
2010-10-26 11:11:13 +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_API));
First pass at adding logging capabilities for the API functions. At the moment it logs the function calls, their arguments and the return values. This is not complete or polished, but I am committing it now, at the request of someone who really wants to use it, even though it's not really done. It currently does not attempt to log all the functions, just the most important ones. I will be making further adjustments to the API logging code over the next few days/weeks. (Suggestions for improvements are welcome). Update the Python build scripts to re-build the swig C++ file whenever the python-extensions.swig file is modified. Correct the help for 'log enable' command (give it the correct number & type of arguments). llvm-svn: 117349
2010-10-26 11:11:13 +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 ("SBProcess(%p)::GetProcessID () => %" PRIu64, process_sp.get(), ret_val);
First pass at adding logging capabilities for the API functions. At the moment it logs the function calls, their arguments and the return values. This is not complete or polished, but I am committing it now, at the request of someone who really wants to use it, even though it's not really done. It currently does not attempt to log all the functions, just the most important ones. I will be making further adjustments to the API logging code over the next few days/weeks. (Suggestions for improvements are welcome). Update the Python build scripts to re-build the swig C++ file whenever the python-extensions.swig file is modified. Correct the help for 'log enable' command (give it the correct number & type of arguments). llvm-svn: 117349
2010-10-26 11:11:13 +08:00
return ret_val;
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
uint32_t
SBProcess::GetUniqueID()
{
uint32_t ret_val = 0;
ProcessSP process_sp(GetSP());
if (process_sp)
ret_val = process_sp->GetUniqueID();
<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_API));
<rdar://problem/13009943> Added a unique integer identifier to processes. Some systems, like JTAG or other simulators, might always assign the same process ID (pid) to the processes that are being debugged. In order for scripts and the APIs to uniquely identify the processes, there needs to be another ID. Now the SBProcess class has: uint32_t SBProcess::GetUniqueID(); This integer ID will help to truly uniquely identify a process and help with appropriate caching that can be associated with a SBProcess object. llvm-svn: 172628
2013-01-17 01:29:04 +08:00
if (log)
log->Printf ("SBProcess(%p)::GetUniqueID () => %" PRIu32, process_sp.get(), ret_val);
return ret_val;
}
Add an API SBProcess::GetByteOrder() and add test cases which utilizes GetByteOrder(), among other SBProcess APIs, to write (int)256 into a memory location of a global variable (int)my_int and reads/checks the variable afterwards. llvm-svn: 126792
2011-03-02 06:56:31 +08:00
ByteOrder
SBProcess::GetByteOrder () const
{
ByteOrder byteOrder = eByteOrderInvalid;
lldb::SBTarget and lldb::SBProcess are now thread hardened. They both still contain shared pointers to the lldb_private::Target and lldb_private::Process objects respectively as we won't want the target or process just going away. Also cleaned up the lldb::SBModule to remove dangerous pointer accessors. For any code the public API files, we should always be grabbing shared pointers to any objects for the current class, and any other classes prior to running code with them. llvm-svn: 149238
2012-01-30 17:04:36 +08:00
ProcessSP process_sp(GetSP());
if (process_sp)
byteOrder = process_sp->GetTarget().GetArchitecture().GetByteOrder();
Add an API SBProcess::GetByteOrder() and add test cases which utilizes GetByteOrder(), among other SBProcess APIs, to write (int)256 into a memory location of a global variable (int)my_int and reads/checks the variable afterwards. llvm-svn: 126792
2011-03-02 06:56:31 +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_API));
Add an API SBProcess::GetByteOrder() and add test cases which utilizes GetByteOrder(), among other SBProcess APIs, to write (int)256 into a memory location of a global variable (int)my_int and reads/checks the variable afterwards. llvm-svn: 126792
2011-03-02 06:56:31 +08:00
if (log)
lldb::SBTarget and lldb::SBProcess are now thread hardened. They both still contain shared pointers to the lldb_private::Target and lldb_private::Process objects respectively as we won't want the target or process just going away. Also cleaned up the lldb::SBModule to remove dangerous pointer accessors. For any code the public API files, we should always be grabbing shared pointers to any objects for the current class, and any other classes prior to running code with them. llvm-svn: 149238
2012-01-30 17:04:36 +08:00
log->Printf ("SBProcess(%p)::GetByteOrder () => %d", process_sp.get(), byteOrder);
Add an API SBProcess::GetByteOrder() and add test cases which utilizes GetByteOrder(), among other SBProcess APIs, to write (int)256 into a memory location of a global variable (int)my_int and reads/checks the variable afterwards. llvm-svn: 126792
2011-03-02 06:56:31 +08:00
return byteOrder;
}
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
uint32_t
SBProcess::GetAddressByteSize () const
{
First pass at adding logging capabilities for the API functions. At the moment it logs the function calls, their arguments and the return values. This is not complete or polished, but I am committing it now, at the request of someone who really wants to use it, even though it's not really done. It currently does not attempt to log all the functions, just the most important ones. I will be making further adjustments to the API logging code over the next few days/weeks. (Suggestions for improvements are welcome). Update the Python build scripts to re-build the swig C++ file whenever the python-extensions.swig file is modified. Correct the help for 'log enable' command (give it the correct number & type of arguments). llvm-svn: 117349
2010-10-26 11:11:13 +08:00
uint32_t size = 0;
lldb::SBTarget and lldb::SBProcess are now thread hardened. They both still contain shared pointers to the lldb_private::Target and lldb_private::Process objects respectively as we won't want the target or process just going away. Also cleaned up the lldb::SBModule to remove dangerous pointer accessors. For any code the public API files, we should always be grabbing shared pointers to any objects for the current class, and any other classes prior to running code with them. llvm-svn: 149238
2012-01-30 17:04:36 +08:00
ProcessSP process_sp(GetSP());
if (process_sp)
size = process_sp->GetTarget().GetArchitecture().GetAddressByteSize();
First pass at adding logging capabilities for the API functions. At the moment it logs the function calls, their arguments and the return values. This is not complete or polished, but I am committing it now, at the request of someone who really wants to use it, even though it's not really done. It currently does not attempt to log all the functions, just the most important ones. I will be making further adjustments to the API logging code over the next few days/weeks. (Suggestions for improvements are welcome). Update the Python build scripts to re-build the swig C++ file whenever the python-extensions.swig file is modified. Correct the help for 'log enable' command (give it the correct number & type of arguments). llvm-svn: 117349
2010-10-26 11:11:13 +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_API));
First pass at adding logging capabilities for the API functions. At the moment it logs the function calls, their arguments and the return values. This is not complete or polished, but I am committing it now, at the request of someone who really wants to use it, even though it's not really done. It currently does not attempt to log all the functions, just the most important ones. I will be making further adjustments to the API logging code over the next few days/weeks. (Suggestions for improvements are welcome). Update the Python build scripts to re-build the swig C++ file whenever the python-extensions.swig file is modified. Correct the help for 'log enable' command (give it the correct number & type of arguments). llvm-svn: 117349
2010-10-26 11:11:13 +08:00
if (log)
lldb::SBTarget and lldb::SBProcess are now thread hardened. They both still contain shared pointers to the lldb_private::Target and lldb_private::Process objects respectively as we won't want the target or process just going away. Also cleaned up the lldb::SBModule to remove dangerous pointer accessors. For any code the public API files, we should always be grabbing shared pointers to any objects for the current class, and any other classes prior to running code with them. llvm-svn: 149238
2012-01-30 17:04:36 +08:00
log->Printf ("SBProcess(%p)::GetAddressByteSize () => %d", process_sp.get(), size);
First pass at adding logging capabilities for the API functions. At the moment it logs the function calls, their arguments and the return values. This is not complete or polished, but I am committing it now, at the request of someone who really wants to use it, even though it's not really done. It currently does not attempt to log all the functions, just the most important ones. I will be making further adjustments to the API logging code over the next few days/weeks. (Suggestions for improvements are welcome). Update the Python build scripts to re-build the swig C++ file whenever the python-extensions.swig file is modified. Correct the help for 'log enable' command (give it the correct number & type of arguments). llvm-svn: 117349
2010-10-26 11:11:13 +08:00
return size;
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
SBError
SBProcess::Continue ()
{
<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_API));
First pass at adding logging capabilities for the API functions. At the moment it logs the function calls, their arguments and the return values. This is not complete or polished, but I am committing it now, at the request of someone who really wants to use it, even though it's not really done. It currently does not attempt to log all the functions, just the most important ones. I will be making further adjustments to the API logging code over the next few days/weeks. (Suggestions for improvements are welcome). Update the Python build scripts to re-build the swig C++ file whenever the python-extensions.swig file is modified. Correct the help for 'log enable' command (give it the correct number & type of arguments). llvm-svn: 117349
2010-10-26 11:11:13 +08:00
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
SBError sb_error;
lldb::SBTarget and lldb::SBProcess are now thread hardened. They both still contain shared pointers to the lldb_private::Target and lldb_private::Process objects respectively as we won't want the target or process just going away. Also cleaned up the lldb::SBModule to remove dangerous pointer accessors. For any code the public API files, we should always be grabbing shared pointers to any objects for the current class, and any other classes prior to running code with them. llvm-svn: 149238
2012-01-30 17:04:36 +08:00
ProcessSP process_sp(GetSP());
if (log)
log->Printf ("SBProcess(%p)::Continue ()...", process_sp.get());
if (process_sp)
Added the first of hopefully many python example scripts that show how to use the python API that is exposed through SWIG to do some cool stuff. Also fixed synchronous debugging so that all process control APIs exposed through the python API will now wait for the process to stop if you set the async mode to false (see disasm.py). llvm-svn: 115738
2010-10-06 11:53:16 +08:00
{
lldb::SBTarget and lldb::SBProcess are now thread hardened. They both still contain shared pointers to the lldb_private::Target and lldb_private::Process objects respectively as we won't want the target or process just going away. Also cleaned up the lldb::SBModule to remove dangerous pointer accessors. For any code the public API files, we should always be grabbing shared pointers to any objects for the current class, and any other classes prior to running code with them. llvm-svn: 149238
2012-01-30 17:04:36 +08:00
Mutex::Locker api_locker (process_sp->GetTarget().GetAPIMutex());
Fixed SBTarget attach calls to properly deal with being connected to a remotely connected process connection. Also added support for more kinds of continue packet when multiple threads need to continue where some want to continue with signals. llvm-svn: 133785
2011-06-24 11:21:43 +08:00
lldb::SBTarget and lldb::SBProcess are now thread hardened. They both still contain shared pointers to the lldb_private::Target and lldb_private::Process objects respectively as we won't want the target or process just going away. Also cleaned up the lldb::SBModule to remove dangerous pointer accessors. For any code the public API files, we should always be grabbing shared pointers to any objects for the current class, and any other classes prior to running code with them. llvm-svn: 149238
2012-01-30 17:04:36 +08:00
Error error (process_sp->Resume());
Added the first of hopefully many python example scripts that show how to use the python API that is exposed through SWIG to do some cool stuff. Also fixed synchronous debugging so that all process control APIs exposed through the python API will now wait for the process to stop if you set the async mode to false (see disasm.py). llvm-svn: 115738
2010-10-06 11:53:16 +08:00
if (error.Success())
{
lldb::SBTarget and lldb::SBProcess are now thread hardened. They both still contain shared pointers to the lldb_private::Target and lldb_private::Process objects respectively as we won't want the target or process just going away. Also cleaned up the lldb::SBModule to remove dangerous pointer accessors. For any code the public API files, we should always be grabbing shared pointers to any objects for the current class, and any other classes prior to running code with them. llvm-svn: 149238
2012-01-30 17:04:36 +08:00
if (process_sp->GetTarget().GetDebugger().GetAsyncExecution () == false)
Improved API logging. llvm-svn: 117772
2010-10-30 12:51:46 +08:00
{
if (log)
lldb::SBTarget and lldb::SBProcess are now thread hardened. They both still contain shared pointers to the lldb_private::Target and lldb_private::Process objects respectively as we won't want the target or process just going away. Also cleaned up the lldb::SBModule to remove dangerous pointer accessors. For any code the public API files, we should always be grabbing shared pointers to any objects for the current class, and any other classes prior to running code with them. llvm-svn: 149238
2012-01-30 17:04:36 +08:00
log->Printf ("SBProcess(%p)::Continue () waiting for process to stop...", process_sp.get());
process_sp->WaitForProcessToStop (NULL);
Improved API logging. llvm-svn: 117772
2010-10-30 12:51:46 +08:00
}
Added the first of hopefully many python example scripts that show how to use the python API that is exposed through SWIG to do some cool stuff. Also fixed synchronous debugging so that all process control APIs exposed through the python API will now wait for the process to stop if you set the async mode to false (see disasm.py). llvm-svn: 115738
2010-10-06 11:53:16 +08:00
}
sb_error.SetError(error);
}
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
else
sb_error.SetErrorString ("SBProcess is invalid");
First pass at adding logging capabilities for the API functions. At the moment it logs the function calls, their arguments and the return values. This is not complete or polished, but I am committing it now, at the request of someone who really wants to use it, even though it's not really done. It currently does not attempt to log all the functions, just the most important ones. I will be making further adjustments to the API logging code over the next few days/weeks. (Suggestions for improvements are welcome). Update the Python build scripts to re-build the swig C++ file whenever the python-extensions.swig file is modified. Correct the help for 'log enable' command (give it the correct number & type of arguments). llvm-svn: 117349
2010-10-26 11:11:13 +08:00
if (log)
{
SBStream sstr;
sb_error.GetDescription (sstr);
lldb::SBTarget and lldb::SBProcess are now thread hardened. They both still contain shared pointers to the lldb_private::Target and lldb_private::Process objects respectively as we won't want the target or process just going away. Also cleaned up the lldb::SBModule to remove dangerous pointer accessors. For any code the public API files, we should always be grabbing shared pointers to any objects for the current class, and any other classes prior to running code with them. llvm-svn: 149238
2012-01-30 17:04:36 +08:00
log->Printf ("SBProcess(%p)::Continue () => SBError (%p): %s", process_sp.get(), sb_error.get(), sstr.GetData());
First pass at adding logging capabilities for the API functions. At the moment it logs the function calls, their arguments and the return values. This is not complete or polished, but I am committing it now, at the request of someone who really wants to use it, even though it's not really done. It currently does not attempt to log all the functions, just the most important ones. I will be making further adjustments to the API logging code over the next few days/weeks. (Suggestions for improvements are welcome). Update the Python build scripts to re-build the swig C++ file whenever the python-extensions.swig file is modified. Correct the help for 'log enable' command (give it the correct number & type of arguments). llvm-svn: 117349
2010-10-26 11:11:13 +08:00
}
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
return sb_error;
}
SBError
SBProcess::Destroy ()
{
SBError sb_error;
lldb::SBTarget and lldb::SBProcess are now thread hardened. They both still contain shared pointers to the lldb_private::Target and lldb_private::Process objects respectively as we won't want the target or process just going away. Also cleaned up the lldb::SBModule to remove dangerous pointer accessors. For any code the public API files, we should always be grabbing shared pointers to any objects for the current class, and any other classes prior to running code with them. llvm-svn: 149238
2012-01-30 17:04:36 +08:00
ProcessSP process_sp(GetSP());
if (process_sp)
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
{
lldb::SBTarget and lldb::SBProcess are now thread hardened. They both still contain shared pointers to the lldb_private::Target and lldb_private::Process objects respectively as we won't want the target or process just going away. Also cleaned up the lldb::SBModule to remove dangerous pointer accessors. For any code the public API files, we should always be grabbing shared pointers to any objects for the current class, and any other classes prior to running code with them. llvm-svn: 149238
2012-01-30 17:04:36 +08:00
Mutex::Locker api_locker (process_sp->GetTarget().GetAPIMutex());
sb_error.SetError(process_sp->Destroy());
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
}
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
else
sb_error.SetErrorString ("SBProcess is invalid");
<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_API));
Improved API logging. llvm-svn: 117772
2010-10-30 12:51:46 +08:00
if (log)
{
SBStream sstr;
sb_error.GetDescription (sstr);
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
log->Printf ("SBProcess(%p)::Destroy () => SBError (%p): %s",
lldb::SBTarget and lldb::SBProcess are now thread hardened. They both still contain shared pointers to the lldb_private::Target and lldb_private::Process objects respectively as we won't want the target or process just going away. Also cleaned up the lldb::SBModule to remove dangerous pointer accessors. For any code the public API files, we should always be grabbing shared pointers to any objects for the current class, and any other classes prior to running code with them. llvm-svn: 149238
2012-01-30 17:04:36 +08:00
process_sp.get(),
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
sb_error.get(),
sstr.GetData());
Improved API logging. llvm-svn: 117772
2010-10-30 12:51:46 +08:00
}
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
return sb_error;
}
SBError
SBProcess::Stop ()
{
SBError sb_error;
lldb::SBTarget and lldb::SBProcess are now thread hardened. They both still contain shared pointers to the lldb_private::Target and lldb_private::Process objects respectively as we won't want the target or process just going away. Also cleaned up the lldb::SBModule to remove dangerous pointer accessors. For any code the public API files, we should always be grabbing shared pointers to any objects for the current class, and any other classes prior to running code with them. llvm-svn: 149238
2012-01-30 17:04:36 +08:00
ProcessSP process_sp(GetSP());
if (process_sp)
The LLDB API (lldb::SB*) is now thread safe! llvm-svn: 122262
2010-12-21 04:49:23 +08:00
{
lldb::SBTarget and lldb::SBProcess are now thread hardened. They both still contain shared pointers to the lldb_private::Target and lldb_private::Process objects respectively as we won't want the target or process just going away. Also cleaned up the lldb::SBModule to remove dangerous pointer accessors. For any code the public API files, we should always be grabbing shared pointers to any objects for the current class, and any other classes prior to running code with them. llvm-svn: 149238
2012-01-30 17:04:36 +08:00
Mutex::Locker api_locker (process_sp->GetTarget().GetAPIMutex());
sb_error.SetError (process_sp->Halt());
The LLDB API (lldb::SB*) is now thread safe! llvm-svn: 122262
2010-12-21 04:49:23 +08:00
}
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
else
sb_error.SetErrorString ("SBProcess is invalid");
First pass at adding logging capabilities for the API functions. At the moment it logs the function calls, their arguments and the return values. This is not complete or polished, but I am committing it now, at the request of someone who really wants to use it, even though it's not really done. It currently does not attempt to log all the functions, just the most important ones. I will be making further adjustments to the API logging code over the next few days/weeks. (Suggestions for improvements are welcome). Update the Python build scripts to re-build the swig C++ file whenever the python-extensions.swig file is modified. Correct the help for 'log enable' command (give it the correct number & type of arguments). llvm-svn: 117349
2010-10-26 11:11:13 +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_API));
First pass at adding logging capabilities for the API functions. At the moment it logs the function calls, their arguments and the return values. This is not complete or polished, but I am committing it now, at the request of someone who really wants to use it, even though it's not really done. It currently does not attempt to log all the functions, just the most important ones. I will be making further adjustments to the API logging code over the next few days/weeks. (Suggestions for improvements are welcome). Update the Python build scripts to re-build the swig C++ file whenever the python-extensions.swig file is modified. Correct the help for 'log enable' command (give it the correct number & type of arguments). llvm-svn: 117349
2010-10-26 11:11:13 +08:00
if (log)
{
SBStream sstr;
sb_error.GetDescription (sstr);
Modified the lldb_private::TypeList to use a std::multimap for quicker lookup by type ID (the most common type of type lookup). Changed the API logging a bit to always show the objects in the OBJECT(POINTER) format so it will be easy to locate all instances of an object or references to it when looking at logs. llvm-svn: 117641
2010-10-29 12:59:35 +08:00
log->Printf ("SBProcess(%p)::Stop () => SBError (%p): %s",
lldb::SBTarget and lldb::SBProcess are now thread hardened. They both still contain shared pointers to the lldb_private::Target and lldb_private::Process objects respectively as we won't want the target or process just going away. Also cleaned up the lldb::SBModule to remove dangerous pointer accessors. For any code the public API files, we should always be grabbing shared pointers to any objects for the current class, and any other classes prior to running code with them. llvm-svn: 149238
2012-01-30 17:04:36 +08:00
process_sp.get(),
Modified the lldb_private::TypeList to use a std::multimap for quicker lookup by type ID (the most common type of type lookup). Changed the API logging a bit to always show the objects in the OBJECT(POINTER) format so it will be easy to locate all instances of an object or references to it when looking at logs. llvm-svn: 117641
2010-10-29 12:59:35 +08:00
sb_error.get(),
Clean up the API logging code: - Try to reduce logging to one line per function call instead of tw - Put all arguments & their values into log for calls - Add 'this' parameter information to function call logging, making it show the appropriate internal pointer (this.obj, this.sp, this.ap...) - Clean up some return values - Remove logging of constructors that construct empty objects - Change '==>' to '=>' for showing result values... - Fix various minor bugs - Add some protected 'get' functions to help getting the internal pointers for the 'this' arguments... llvm-svn: 117417
2010-10-27 07:49:36 +08:00
sstr.GetData());
First pass at adding logging capabilities for the API functions. At the moment it logs the function calls, their arguments and the return values. This is not complete or polished, but I am committing it now, at the request of someone who really wants to use it, even though it's not really done. It currently does not attempt to log all the functions, just the most important ones. I will be making further adjustments to the API logging code over the next few days/weeks. (Suggestions for improvements are welcome). Update the Python build scripts to re-build the swig C++ file whenever the python-extensions.swig file is modified. Correct the help for 'log enable' command (give it the correct number & type of arguments). llvm-svn: 117349
2010-10-26 11:11:13 +08:00
}
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
return sb_error;
}
SBError
SBProcess::Kill ()
{
SBError sb_error;
lldb::SBTarget and lldb::SBProcess are now thread hardened. They both still contain shared pointers to the lldb_private::Target and lldb_private::Process objects respectively as we won't want the target or process just going away. Also cleaned up the lldb::SBModule to remove dangerous pointer accessors. For any code the public API files, we should always be grabbing shared pointers to any objects for the current class, and any other classes prior to running code with them. llvm-svn: 149238
2012-01-30 17:04:36 +08:00
ProcessSP process_sp(GetSP());
if (process_sp)
The LLDB API (lldb::SB*) is now thread safe! llvm-svn: 122262
2010-12-21 04:49:23 +08:00
{
lldb::SBTarget and lldb::SBProcess are now thread hardened. They both still contain shared pointers to the lldb_private::Target and lldb_private::Process objects respectively as we won't want the target or process just going away. Also cleaned up the lldb::SBModule to remove dangerous pointer accessors. For any code the public API files, we should always be grabbing shared pointers to any objects for the current class, and any other classes prior to running code with them. llvm-svn: 149238
2012-01-30 17:04:36 +08:00
Mutex::Locker api_locker (process_sp->GetTarget().GetAPIMutex());
sb_error.SetError (process_sp->Destroy());
The LLDB API (lldb::SB*) is now thread safe! llvm-svn: 122262
2010-12-21 04:49:23 +08:00
}
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
else
sb_error.SetErrorString ("SBProcess is invalid");
First pass at adding logging capabilities for the API functions. At the moment it logs the function calls, their arguments and the return values. This is not complete or polished, but I am committing it now, at the request of someone who really wants to use it, even though it's not really done. It currently does not attempt to log all the functions, just the most important ones. I will be making further adjustments to the API logging code over the next few days/weeks. (Suggestions for improvements are welcome). Update the Python build scripts to re-build the swig C++ file whenever the python-extensions.swig file is modified. Correct the help for 'log enable' command (give it the correct number & type of arguments). llvm-svn: 117349
2010-10-26 11:11:13 +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_API));
First pass at adding logging capabilities for the API functions. At the moment it logs the function calls, their arguments and the return values. This is not complete or polished, but I am committing it now, at the request of someone who really wants to use it, even though it's not really done. It currently does not attempt to log all the functions, just the most important ones. I will be making further adjustments to the API logging code over the next few days/weeks. (Suggestions for improvements are welcome). Update the Python build scripts to re-build the swig C++ file whenever the python-extensions.swig file is modified. Correct the help for 'log enable' command (give it the correct number & type of arguments). llvm-svn: 117349
2010-10-26 11:11:13 +08:00
if (log)
{
SBStream sstr;
sb_error.GetDescription (sstr);
Modified the lldb_private::TypeList to use a std::multimap for quicker lookup by type ID (the most common type of type lookup). Changed the API logging a bit to always show the objects in the OBJECT(POINTER) format so it will be easy to locate all instances of an object or references to it when looking at logs. llvm-svn: 117641
2010-10-29 12:59:35 +08:00
log->Printf ("SBProcess(%p)::Kill () => SBError (%p): %s",
lldb::SBTarget and lldb::SBProcess are now thread hardened. They both still contain shared pointers to the lldb_private::Target and lldb_private::Process objects respectively as we won't want the target or process just going away. Also cleaned up the lldb::SBModule to remove dangerous pointer accessors. For any code the public API files, we should always be grabbing shared pointers to any objects for the current class, and any other classes prior to running code with them. llvm-svn: 149238
2012-01-30 17:04:36 +08:00
process_sp.get(),
Modified the lldb_private::TypeList to use a std::multimap for quicker lookup by type ID (the most common type of type lookup). Changed the API logging a bit to always show the objects in the OBJECT(POINTER) format so it will be easy to locate all instances of an object or references to it when looking at logs. llvm-svn: 117641
2010-10-29 12:59:35 +08:00
sb_error.get(),
Clean up the API logging code: - Try to reduce logging to one line per function call instead of tw - Put all arguments & their values into log for calls - Add 'this' parameter information to function call logging, making it show the appropriate internal pointer (this.obj, this.sp, this.ap...) - Clean up some return values - Remove logging of constructors that construct empty objects - Change '==>' to '=>' for showing result values... - Fix various minor bugs - Add some protected 'get' functions to help getting the internal pointers for the 'this' arguments... llvm-svn: 117417
2010-10-27 07:49:36 +08:00
sstr.GetData());
First pass at adding logging capabilities for the API functions. At the moment it logs the function calls, their arguments and the return values. This is not complete or polished, but I am committing it now, at the request of someone who really wants to use it, even though it's not really done. It currently does not attempt to log all the functions, just the most important ones. I will be making further adjustments to the API logging code over the next few days/weeks. (Suggestions for improvements are welcome). Update the Python build scripts to re-build the swig C++ file whenever the python-extensions.swig file is modified. Correct the help for 'log enable' command (give it the correct number & type of arguments). llvm-svn: 117349
2010-10-26 11:11:13 +08:00
}
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
return sb_error;
}
SBError
SBProcess::Detach ()
Recommitting r180831 with trivial fix - remember to return errors if you compute. llvm-svn: 180898
2013-05-02 08:27:30 +08:00
{
// FIXME: This should come from a process default.
bool keep_stopped = false;
return Detach (keep_stopped);
}
SBError
SBProcess::Detach (bool keep_stopped)
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
{
SBError sb_error;
lldb::SBTarget and lldb::SBProcess are now thread hardened. They both still contain shared pointers to the lldb_private::Target and lldb_private::Process objects respectively as we won't want the target or process just going away. Also cleaned up the lldb::SBModule to remove dangerous pointer accessors. For any code the public API files, we should always be grabbing shared pointers to any objects for the current class, and any other classes prior to running code with them. llvm-svn: 149238
2012-01-30 17:04:36 +08:00
ProcessSP process_sp(GetSP());
if (process_sp)
The LLDB API (lldb::SB*) is now thread safe! llvm-svn: 122262
2010-12-21 04:49:23 +08:00
{
lldb::SBTarget and lldb::SBProcess are now thread hardened. They both still contain shared pointers to the lldb_private::Target and lldb_private::Process objects respectively as we won't want the target or process just going away. Also cleaned up the lldb::SBModule to remove dangerous pointer accessors. For any code the public API files, we should always be grabbing shared pointers to any objects for the current class, and any other classes prior to running code with them. llvm-svn: 149238
2012-01-30 17:04:36 +08:00
Mutex::Locker api_locker (process_sp->GetTarget().GetAPIMutex());
Recommitting r180831 with trivial fix - remember to return errors if you compute. llvm-svn: 180898
2013-05-02 08:27:30 +08:00
sb_error.SetError (process_sp->Detach(keep_stopped));
The LLDB API (lldb::SB*) is now thread safe! llvm-svn: 122262
2010-12-21 04:49:23 +08:00
}
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
else
sb_error.SetErrorString ("SBProcess is invalid");
return sb_error;
}
SBError
Improved API logging. llvm-svn: 117772
2010-10-30 12:51:46 +08:00
SBProcess::Signal (int signo)
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
{
SBError sb_error;
lldb::SBTarget and lldb::SBProcess are now thread hardened. They both still contain shared pointers to the lldb_private::Target and lldb_private::Process objects respectively as we won't want the target or process just going away. Also cleaned up the lldb::SBModule to remove dangerous pointer accessors. For any code the public API files, we should always be grabbing shared pointers to any objects for the current class, and any other classes prior to running code with them. llvm-svn: 149238
2012-01-30 17:04:36 +08:00
ProcessSP process_sp(GetSP());
if (process_sp)
The LLDB API (lldb::SB*) is now thread safe! llvm-svn: 122262
2010-12-21 04:49:23 +08:00
{
lldb::SBTarget and lldb::SBProcess are now thread hardened. They both still contain shared pointers to the lldb_private::Target and lldb_private::Process objects respectively as we won't want the target or process just going away. Also cleaned up the lldb::SBModule to remove dangerous pointer accessors. For any code the public API files, we should always be grabbing shared pointers to any objects for the current class, and any other classes prior to running code with them. llvm-svn: 149238
2012-01-30 17:04:36 +08:00
Mutex::Locker api_locker (process_sp->GetTarget().GetAPIMutex());
sb_error.SetError (process_sp->Signal (signo));
The LLDB API (lldb::SB*) is now thread safe! llvm-svn: 122262
2010-12-21 04:49:23 +08:00
}
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
else
sb_error.SetErrorString ("SBProcess is invalid");
<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_API));
Improved API logging. llvm-svn: 117772
2010-10-30 12:51:46 +08:00
if (log)
{
SBStream sstr;
sb_error.GetDescription (sstr);
log->Printf ("SBProcess(%p)::Signal (signo=%i) => SBError (%p): %s",
lldb::SBTarget and lldb::SBProcess are now thread hardened. They both still contain shared pointers to the lldb_private::Target and lldb_private::Process objects respectively as we won't want the target or process just going away. Also cleaned up the lldb::SBModule to remove dangerous pointer accessors. For any code the public API files, we should always be grabbing shared pointers to any objects for the current class, and any other classes prior to running code with them. llvm-svn: 149238
2012-01-30 17:04:36 +08:00
process_sp.get(),
Improved API logging. llvm-svn: 117772
2010-10-30 12:51:46 +08:00
signo,
sb_error.get(),
sstr.GetData());
}
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
return sb_error;
}
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
SBProcess::SendAsyncInterrupt ()
{
ProcessSP process_sp(GetSP());
if (process_sp)
{
process_sp->SendAsyncInterrupt ();
}
}
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
SBThread
Improved API logging. llvm-svn: 117772
2010-10-30 12:51:46 +08:00
SBProcess::GetThreadByID (tid_t tid)
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
{
Improved API logging. llvm-svn: 117772
2010-10-30 12:51:46 +08:00
SBThread sb_thread;
Removed the "lldb-forward-rtti.h" header file as it was designed to contain all RTTI types, and since we don't use RTTI anymore since clang and llvm don't we don't really need this header file. All shared pointer definitions have been moved into "lldb-forward.h". Defined std::tr1::weak_ptr definitions for all of the types that inherit from enable_shared_from_this() in "lldb-forward.h" in preparation for thread hardening our public API. The first in the thread hardening check-ins. First we start with SBThread. We have issues in our lldb::SB API right now where if you have one object that is being used by two threads we have a race condition. Consider the following code: 1 int 2 SBThread::SomeFunction() 3 { 4 int result = -1; 5 if (m_opaque_sp) 6 { 7 result = m_opaque_sp->DoSomething(); 8 } 9 return result; 10 } And now this happens: Thread 1 enters any SBThread function and checks its m_opaque_sp and is about to execute the code on line 7 but hasn't yet Thread 2 gets to run and class sb_thread.Clear() which calls m_opaque_sp.clear() and clears the contents of the shared pointer member Thread 1 now crashes when it resumes. The solution is to use std::tr1::weak_ptr. Now the SBThread class contains a lldb::ThreadWP (weak pointer to our lldb_private::Thread class) and this function would look like: 1 int 2 SBThread::SomeFunction() 3 { 4 int result = -1; 5 ThreadSP thread_sp(m_opaque_wp.lock()); 6 if (thread_sp) 7 { 8 result = m_opaque_sp->DoSomething(); 9 } 10 return result; 11 } Now we have a solid thread safe API where we get a local copy of our thread shared pointer from our weak_ptr and then we are guaranteed it can't go away during our function. So lldb::SBThread has been thread hardened, more checkins to follow shortly. llvm-svn: 149218
2012-01-30 10:53:15 +08:00
ThreadSP thread_sp;
lldb::SBTarget and lldb::SBProcess are now thread hardened. They both still contain shared pointers to the lldb_private::Target and lldb_private::Process objects respectively as we won't want the target or process just going away. Also cleaned up the lldb::SBModule to remove dangerous pointer accessors. For any code the public API files, we should always be grabbing shared pointers to any objects for the current class, and any other classes prior to running code with them. llvm-svn: 149238
2012-01-30 17:04:36 +08:00
ProcessSP process_sp(GetSP());
if (process_sp)
The LLDB API (lldb::SB*) is now thread safe! llvm-svn: 122262
2010-12-21 04:49:23 +08:00
{
lldb::SBTarget and lldb::SBProcess are now thread hardened. They both still contain shared pointers to the lldb_private::Target and lldb_private::Process objects respectively as we won't want the target or process just going away. Also cleaned up the lldb::SBModule to remove dangerous pointer accessors. For any code the public API files, we should always be grabbing shared pointers to any objects for the current class, and any other classes prior to running code with them. llvm-svn: 149238
2012-01-30 17:04:36 +08:00
Mutex::Locker api_locker (process_sp->GetTarget().GetAPIMutex());
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
Process::StopLocker stop_locker;
const bool can_update = stop_locker.TryLock(&process_sp->GetRunLock());
thread_sp = process_sp->GetThreadList().FindThreadByID (tid, can_update);
Removed the "lldb-forward-rtti.h" header file as it was designed to contain all RTTI types, and since we don't use RTTI anymore since clang and llvm don't we don't really need this header file. All shared pointer definitions have been moved into "lldb-forward.h". Defined std::tr1::weak_ptr definitions for all of the types that inherit from enable_shared_from_this() in "lldb-forward.h" in preparation for thread hardening our public API. The first in the thread hardening check-ins. First we start with SBThread. We have issues in our lldb::SB API right now where if you have one object that is being used by two threads we have a race condition. Consider the following code: 1 int 2 SBThread::SomeFunction() 3 { 4 int result = -1; 5 if (m_opaque_sp) 6 { 7 result = m_opaque_sp->DoSomething(); 8 } 9 return result; 10 } And now this happens: Thread 1 enters any SBThread function and checks its m_opaque_sp and is about to execute the code on line 7 but hasn't yet Thread 2 gets to run and class sb_thread.Clear() which calls m_opaque_sp.clear() and clears the contents of the shared pointer member Thread 1 now crashes when it resumes. The solution is to use std::tr1::weak_ptr. Now the SBThread class contains a lldb::ThreadWP (weak pointer to our lldb_private::Thread class) and this function would look like: 1 int 2 SBThread::SomeFunction() 3 { 4 int result = -1; 5 ThreadSP thread_sp(m_opaque_wp.lock()); 6 if (thread_sp) 7 { 8 result = m_opaque_sp->DoSomething(); 9 } 10 return result; 11 } Now we have a solid thread safe API where we get a local copy of our thread shared pointer from our weak_ptr and then we are guaranteed it can't go away during our function. So lldb::SBThread has been thread hardened, more checkins to follow shortly. llvm-svn: 149218
2012-01-30 10:53:15 +08:00
sb_thread.SetThread (thread_sp);
The LLDB API (lldb::SB*) is now thread safe! llvm-svn: 122262
2010-12-21 04:49:23 +08:00
}
Improved API logging. llvm-svn: 117772
2010-10-30 12:51:46 +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_API));
Improved API logging. llvm-svn: 117772
2010-10-30 12:51:46 +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 ("SBProcess(%p)::GetThreadByID (tid=0x%4.4" PRIx64 ") => SBThread (%p)",
lldb::SBTarget and lldb::SBProcess are now thread hardened. They both still contain shared pointers to the lldb_private::Target and lldb_private::Process objects respectively as we won't want the target or process just going away. Also cleaned up the lldb::SBModule to remove dangerous pointer accessors. For any code the public API files, we should always be grabbing shared pointers to any objects for the current class, and any other classes prior to running code with them. llvm-svn: 149238
2012-01-30 17:04:36 +08:00
process_sp.get(),
Improved API logging. llvm-svn: 117772
2010-10-30 12:51:46 +08:00
tid,
Removed the "lldb-forward-rtti.h" header file as it was designed to contain all RTTI types, and since we don't use RTTI anymore since clang and llvm don't we don't really need this header file. All shared pointer definitions have been moved into "lldb-forward.h". Defined std::tr1::weak_ptr definitions for all of the types that inherit from enable_shared_from_this() in "lldb-forward.h" in preparation for thread hardening our public API. The first in the thread hardening check-ins. First we start with SBThread. We have issues in our lldb::SB API right now where if you have one object that is being used by two threads we have a race condition. Consider the following code: 1 int 2 SBThread::SomeFunction() 3 { 4 int result = -1; 5 if (m_opaque_sp) 6 { 7 result = m_opaque_sp->DoSomething(); 8 } 9 return result; 10 } And now this happens: Thread 1 enters any SBThread function and checks its m_opaque_sp and is about to execute the code on line 7 but hasn't yet Thread 2 gets to run and class sb_thread.Clear() which calls m_opaque_sp.clear() and clears the contents of the shared pointer member Thread 1 now crashes when it resumes. The solution is to use std::tr1::weak_ptr. Now the SBThread class contains a lldb::ThreadWP (weak pointer to our lldb_private::Thread class) and this function would look like: 1 int 2 SBThread::SomeFunction() 3 { 4 int result = -1; 5 ThreadSP thread_sp(m_opaque_wp.lock()); 6 if (thread_sp) 7 { 8 result = m_opaque_sp->DoSomething(); 9 } 10 return result; 11 } Now we have a solid thread safe API where we get a local copy of our thread shared pointer from our weak_ptr and then we are guaranteed it can't go away during our function. So lldb::SBThread has been thread hardened, more checkins to follow shortly. llvm-svn: 149218
2012-01-30 10:53:15 +08:00
thread_sp.get());
Improved API logging. llvm-svn: 117772
2010-10-30 12:51:46 +08:00
}
return sb_thread;
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
Add accessors on process to get & set the selected thread by IndexID (useful since that's the one that "thread list" shows and it won't get reused even if the underlying system thread ID gets reused. llvm-svn: 160187
2012-07-14 04:18:18 +08:00
SBThread
SBProcess::GetThreadByIndexID (uint32_t index_id)
{
SBThread sb_thread;
ThreadSP thread_sp;
ProcessSP process_sp(GetSP());
if (process_sp)
{
Mutex::Locker api_locker (process_sp->GetTarget().GetAPIMutex());
Process::StopLocker stop_locker;
const bool can_update = stop_locker.TryLock(&process_sp->GetRunLock());
thread_sp = process_sp->GetThreadList().FindThreadByIndexID (index_id, can_update);
sb_thread.SetThread (thread_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_API));
Add accessors on process to get & set the selected thread by IndexID (useful since that's the one that "thread list" shows and it won't get reused even if the underlying system thread ID gets reused. llvm-svn: 160187
2012-07-14 04:18:18 +08:00
if (log)
{
log->Printf ("SBProcess(%p)::GetThreadByID (tid=0x%x) => SBThread (%p)",
process_sp.get(),
index_id,
thread_sp.get());
}
return sb_thread;
}
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
StateType
SBProcess::GetStateFromEvent (const SBEvent &event)
{
<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_API));
First pass at adding logging capabilities for the API functions. At the moment it logs the function calls, their arguments and the return values. This is not complete or polished, but I am committing it now, at the request of someone who really wants to use it, even though it's not really done. It currently does not attempt to log all the functions, just the most important ones. I will be making further adjustments to the API logging code over the next few days/weeks. (Suggestions for improvements are welcome). Update the Python build scripts to re-build the swig C++ file whenever the python-extensions.swig file is modified. Correct the help for 'log enable' command (give it the correct number & type of arguments). llvm-svn: 117349
2010-10-26 11:11:13 +08:00
StateType ret_val = Process::ProcessEventData::GetStateFromEvent (event.get());
if (log)
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
log->Printf ("SBProcess::GetStateFromEvent (event.sp=%p) => %s", event.get(),
Clean up the API logging code: - Try to reduce logging to one line per function call instead of tw - Put all arguments & their values into log for calls - Add 'this' parameter information to function call logging, making it show the appropriate internal pointer (this.obj, this.sp, this.ap...) - Clean up some return values - Remove logging of constructors that construct empty objects - Change '==>' to '=>' for showing result values... - Fix various minor bugs - Add some protected 'get' functions to help getting the internal pointers for the 'this' arguments... llvm-svn: 117417
2010-10-27 07:49:36 +08:00
lldb_private::StateAsCString (ret_val));
First pass at adding logging capabilities for the API functions. At the moment it logs the function calls, their arguments and the return values. This is not complete or polished, but I am committing it now, at the request of someone who really wants to use it, even though it's not really done. It currently does not attempt to log all the functions, just the most important ones. I will be making further adjustments to the API logging code over the next few days/weeks. (Suggestions for improvements are welcome). Update the Python build scripts to re-build the swig C++ file whenever the python-extensions.swig file is modified. Correct the help for 'log enable' command (give it the correct number & type of arguments). llvm-svn: 117349
2010-10-26 11:11:13 +08:00
return ret_val;
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
bool
SBProcess::GetRestartedFromEvent (const SBEvent &event)
{
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
return Process::ProcessEventData::GetRestartedFromEvent (event.get());
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
size_t
SBProcess::GetNumRestartedReasonsFromEvent (const lldb::SBEvent &event)
{
return Process::ProcessEventData::GetNumRestartedReasons(event.get());
}
const char *
SBProcess::GetRestartedReasonAtIndexFromEvent (const lldb::SBEvent &event, size_t idx)
{
return Process::ProcessEventData::GetRestartedReasonAtIndex(event.get(), idx);
}
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
SBProcess
SBProcess::GetProcessFromEvent (const SBEvent &event)
{
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
SBProcess process(Process::ProcessEventData::GetProcessFromEvent (event.get()));
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
return process;
}
Send Breakpoint Changed events for all the relevant changes to breakpoints. Also, provide and use accessors for the thread options on breakpoints so we can control sending the appropriate events. llvm-svn: 150057
2012-02-08 13:23:15 +08:00
bool
SBProcess::EventIsProcessEvent (const SBEvent &event)
{
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
return strcmp (event.GetBroadcasterClass(), SBProcess::GetBroadcasterClass()) == 0;
Send Breakpoint Changed events for all the relevant changes to breakpoints. Also, provide and use accessors for the thread options on breakpoints so we can control sending the appropriate events. llvm-svn: 150057
2012-02-08 13:23:15 +08:00
}
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
SBBroadcaster
SBProcess::GetBroadcaster () const
{
<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_API));
First pass at adding logging capabilities for the API functions. At the moment it logs the function calls, their arguments and the return values. This is not complete or polished, but I am committing it now, at the request of someone who really wants to use it, even though it's not really done. It currently does not attempt to log all the functions, just the most important ones. I will be making further adjustments to the API logging code over the next few days/weeks. (Suggestions for improvements are welcome). Update the Python build scripts to re-build the swig C++ file whenever the python-extensions.swig file is modified. Correct the help for 'log enable' command (give it the correct number & type of arguments). llvm-svn: 117349
2010-10-26 11:11:13 +08:00
lldb::SBTarget and lldb::SBProcess are now thread hardened. They both still contain shared pointers to the lldb_private::Target and lldb_private::Process objects respectively as we won't want the target or process just going away. Also cleaned up the lldb::SBModule to remove dangerous pointer accessors. For any code the public API files, we should always be grabbing shared pointers to any objects for the current class, and any other classes prior to running code with them. llvm-svn: 149238
2012-01-30 17:04:36 +08:00
ProcessSP process_sp(GetSP());
SBBroadcaster broadcaster(process_sp.get(), false);
First pass at adding logging capabilities for the API functions. At the moment it logs the function calls, their arguments and the return values. This is not complete or polished, but I am committing it now, at the request of someone who really wants to use it, even though it's not really done. It currently does not attempt to log all the functions, just the most important ones. I will be making further adjustments to the API logging code over the next few days/weeks. (Suggestions for improvements are welcome). Update the Python build scripts to re-build the swig C++ file whenever the python-extensions.swig file is modified. Correct the help for 'log enable' command (give it the correct number & type of arguments). llvm-svn: 117349
2010-10-26 11:11:13 +08:00
if (log)
lldb::SBTarget and lldb::SBProcess are now thread hardened. They both still contain shared pointers to the lldb_private::Target and lldb_private::Process objects respectively as we won't want the target or process just going away. Also cleaned up the lldb::SBModule to remove dangerous pointer accessors. For any code the public API files, we should always be grabbing shared pointers to any objects for the current class, and any other classes prior to running code with them. llvm-svn: 149238
2012-01-30 17:04:36 +08:00
log->Printf ("SBProcess(%p)::GetBroadcaster () => SBBroadcaster (%p)", process_sp.get(),
Clean up the API logging code: - Try to reduce logging to one line per function call instead of tw - Put all arguments & their values into log for calls - Add 'this' parameter information to function call logging, making it show the appropriate internal pointer (this.obj, this.sp, this.ap...) - Clean up some return values - Remove logging of constructors that construct empty objects - Change '==>' to '=>' for showing result values... - Fix various minor bugs - Add some protected 'get' functions to help getting the internal pointers for the 'this' arguments... llvm-svn: 117417
2010-10-27 07:49:36 +08:00
broadcaster.get());
First pass at adding logging capabilities for the API functions. At the moment it logs the function calls, their arguments and the return values. This is not complete or polished, but I am committing it now, at the request of someone who really wants to use it, even though it's not really done. It currently does not attempt to log all the functions, just the most important ones. I will be making further adjustments to the API logging code over the next few days/weeks. (Suggestions for improvements are welcome). Update the Python build scripts to re-build the swig C++ file whenever the python-extensions.swig file is modified. Correct the help for 'log enable' command (give it the correct number & type of arguments). llvm-svn: 117349
2010-10-26 11:11:13 +08:00
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
return broadcaster;
}
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
const char *
SBProcess::GetBroadcasterClass ()
{
return Process::GetStaticBroadcasterClass().AsCString();
}
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
size_t
SBProcess::ReadMemory (addr_t addr, void *dst, size_t dst_len, SBError &sb_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_API));
First pass at adding logging capabilities for the API functions. At the moment it logs the function calls, their arguments and the return values. This is not complete or polished, but I am committing it now, at the request of someone who really wants to use it, even though it's not really done. It currently does not attempt to log all the functions, just the most important ones. I will be making further adjustments to the API logging code over the next few days/weeks. (Suggestions for improvements are welcome). Update the Python build scripts to re-build the swig C++ file whenever the python-extensions.swig file is modified. Correct the help for 'log enable' command (give it the correct number & type of arguments). llvm-svn: 117349
2010-10-26 11:11:13 +08:00
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
size_t bytes_read = 0;
lldb::SBTarget and lldb::SBProcess are now thread hardened. They both still contain shared pointers to the lldb_private::Target and lldb_private::Process objects respectively as we won't want the target or process just going away. Also cleaned up the lldb::SBModule to remove dangerous pointer accessors. For any code the public API files, we should always be grabbing shared pointers to any objects for the current class, and any other classes prior to running code with them. llvm-svn: 149238
2012-01-30 17:04:36 +08:00
ProcessSP process_sp(GetSP());
Improved API logging. llvm-svn: 117772
2010-10-30 12:51:46 +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 ("SBProcess(%p)::ReadMemory (addr=0x%" PRIx64 ", dst=%p, dst_len=%" PRIu64 ", SBError (%p))...",
lldb::SBTarget and lldb::SBProcess are now thread hardened. They both still contain shared pointers to the lldb_private::Target and lldb_private::Process objects respectively as we won't want the target or process just going away. Also cleaned up the lldb::SBModule to remove dangerous pointer accessors. For any code the public API files, we should always be grabbing shared pointers to any objects for the current class, and any other classes prior to running code with them. llvm-svn: 149238
2012-01-30 17:04:36 +08:00
process_sp.get(),
Improved API logging. llvm-svn: 117772
2010-10-30 12:51:46 +08:00
addr,
dst,
Stop using the "%z" size_t modifier and cast all size_t values to uint64_t. Some platforms don't support this modification. llvm-svn: 164148
2012-09-19 02:04:04 +08:00
(uint64_t)dst_len,
Improved API logging. llvm-svn: 117772
2010-10-30 12:51:46 +08:00
sb_error.get());
}
lldb::SBTarget and lldb::SBProcess are now thread hardened. They both still contain shared pointers to the lldb_private::Target and lldb_private::Process objects respectively as we won't want the target or process just going away. Also cleaned up the lldb::SBModule to remove dangerous pointer accessors. For any code the public API files, we should always be grabbing shared pointers to any objects for the current class, and any other classes prior to running code with them. llvm-svn: 149238
2012-01-30 17:04:36 +08:00
if (process_sp)
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +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
Process::StopLocker stop_locker;
if (stop_locker.TryLock(&process_sp->GetRunLock()))
{
Mutex::Locker api_locker (process_sp->GetTarget().GetAPIMutex());
bytes_read = process_sp->ReadMemory (addr, dst, dst_len, sb_error.ref());
}
else
{
Added logging when API calls try to do something that shouldn't be done when the process is stopped by having logging calls that end with "error: process is running". Also test for the process to be stopped when many SBValue API calls are made to make sure it is safe to evaluate values, children of values and much more. llvm-svn: 154160
2012-04-06 10:17:47 +08:00
if (log)
log->Printf ("SBProcess(%p)::ReadMemory() => error: process is running", process_sp.get());
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
sb_error.SetErrorString("process is running");
}
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
else
{
sb_error.SetErrorString ("SBProcess is invalid");
}
First pass at adding logging capabilities for the API functions. At the moment it logs the function calls, their arguments and the return values. This is not complete or polished, but I am committing it now, at the request of someone who really wants to use it, even though it's not really done. It currently does not attempt to log all the functions, just the most important ones. I will be making further adjustments to the API logging code over the next few days/weeks. (Suggestions for improvements are welcome). Update the Python build scripts to re-build the swig C++ file whenever the python-extensions.swig file is modified. Correct the help for 'log enable' command (give it the correct number & type of arguments). llvm-svn: 117349
2010-10-26 11:11:13 +08:00
if (log)
Modified the lldb_private::TypeList to use a std::multimap for quicker lookup by type ID (the most common type of type lookup). Changed the API logging a bit to always show the objects in the OBJECT(POINTER) format so it will be easy to locate all instances of an object or references to it when looking at logs. llvm-svn: 117641
2010-10-29 12:59:35 +08:00
{
SBStream sstr;
sb_error.GetDescription (sstr);
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 ("SBProcess(%p)::ReadMemory (addr=0x%" PRIx64 ", dst=%p, dst_len=%" PRIu64 ", SBError (%p): %s) => %" PRIu64,
lldb::SBTarget and lldb::SBProcess are now thread hardened. They both still contain shared pointers to the lldb_private::Target and lldb_private::Process objects respectively as we won't want the target or process just going away. Also cleaned up the lldb::SBModule to remove dangerous pointer accessors. For any code the public API files, we should always be grabbing shared pointers to any objects for the current class, and any other classes prior to running code with them. llvm-svn: 149238
2012-01-30 17:04:36 +08:00
process_sp.get(),
Modified the lldb_private::TypeList to use a std::multimap for quicker lookup by type ID (the most common type of type lookup). Changed the API logging a bit to always show the objects in the OBJECT(POINTER) format so it will be easy to locate all instances of an object or references to it when looking at logs. llvm-svn: 117641
2010-10-29 12:59:35 +08:00
addr,
dst,
Stop using the "%z" size_t modifier and cast all size_t values to uint64_t. Some platforms don't support this modification. llvm-svn: 164148
2012-09-19 02:04:04 +08:00
(uint64_t)dst_len,
Modified the lldb_private::TypeList to use a std::multimap for quicker lookup by type ID (the most common type of type lookup). Changed the API logging a bit to always show the objects in the OBJECT(POINTER) format so it will be easy to locate all instances of an object or references to it when looking at logs. llvm-svn: 117641
2010-10-29 12:59:35 +08:00
sb_error.get(),
sstr.GetData(),
Stop using the "%z" size_t modifier and cast all size_t values to uint64_t. Some platforms don't support this modification. llvm-svn: 164148
2012-09-19 02:04:04 +08:00
(uint64_t)bytes_read);
Modified the lldb_private::TypeList to use a std::multimap for quicker lookup by type ID (the most common type of type lookup). Changed the API logging a bit to always show the objects in the OBJECT(POINTER) format so it will be easy to locate all instances of an object or references to it when looking at logs. llvm-svn: 117641
2010-10-29 12:59:35 +08:00
}
First pass at adding logging capabilities for the API functions. At the moment it logs the function calls, their arguments and the return values. This is not complete or polished, but I am committing it now, at the request of someone who really wants to use it, even though it's not really done. It currently does not attempt to log all the functions, just the most important ones. I will be making further adjustments to the API logging code over the next few days/weeks. (Suggestions for improvements are welcome). Update the Python build scripts to re-build the swig C++ file whenever the python-extensions.swig file is modified. Correct the help for 'log enable' command (give it the correct number & type of arguments). llvm-svn: 117349
2010-10-26 11:11:13 +08:00
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
return bytes_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
size_t
SBProcess::ReadCStringFromMemory (addr_t addr, void *buf, size_t size, lldb::SBError &sb_error)
{
size_t bytes_read = 0;
lldb::SBTarget and lldb::SBProcess are now thread hardened. They both still contain shared pointers to the lldb_private::Target and lldb_private::Process objects respectively as we won't want the target or process just going away. Also cleaned up the lldb::SBModule to remove dangerous pointer accessors. For any code the public API files, we should always be grabbing shared pointers to any objects for the current class, and any other classes prior to running code with them. llvm-svn: 149238
2012-01-30 17:04:36 +08:00
ProcessSP process_sp(GetSP());
if (process_sp)
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
{
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
Process::StopLocker stop_locker;
if (stop_locker.TryLock(&process_sp->GetRunLock()))
{
Mutex::Locker api_locker (process_sp->GetTarget().GetAPIMutex());
bytes_read = process_sp->ReadCStringFromMemory (addr, (char *)buf, size, sb_error.ref());
}
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_API));
Added logging when API calls try to do something that shouldn't be done when the process is stopped by having logging calls that end with "error: process is running". Also test for the process to be stopped when many SBValue API calls are made to make sure it is safe to evaluate values, children of values and much more. llvm-svn: 154160
2012-04-06 10:17:47 +08:00
if (log)
log->Printf ("SBProcess(%p)::ReadCStringFromMemory() => error: process is running", process_sp.get());
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
sb_error.SetErrorString("process is running");
}
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
{
sb_error.SetErrorString ("SBProcess is invalid");
}
return bytes_read;
}
uint64_t
SBProcess::ReadUnsignedFromMemory (addr_t addr, uint32_t byte_size, lldb::SBError &sb_error)
{
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
uint64_t value = 0;
lldb::SBTarget and lldb::SBProcess are now thread hardened. They both still contain shared pointers to the lldb_private::Target and lldb_private::Process objects respectively as we won't want the target or process just going away. Also cleaned up the lldb::SBModule to remove dangerous pointer accessors. For any code the public API files, we should always be grabbing shared pointers to any objects for the current class, and any other classes prior to running code with them. llvm-svn: 149238
2012-01-30 17:04:36 +08:00
ProcessSP process_sp(GetSP());
if (process_sp)
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
{
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
Process::StopLocker stop_locker;
if (stop_locker.TryLock(&process_sp->GetRunLock()))
{
Mutex::Locker api_locker (process_sp->GetTarget().GetAPIMutex());
value = process_sp->ReadUnsignedIntegerFromMemory (addr, byte_size, 0, sb_error.ref());
}
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_API));
Added logging when API calls try to do something that shouldn't be done when the process is stopped by having logging calls that end with "error: process is running". Also test for the process to be stopped when many SBValue API calls are made to make sure it is safe to evaluate values, children of values and much more. llvm-svn: 154160
2012-04-06 10:17:47 +08:00
if (log)
log->Printf ("SBProcess(%p)::ReadUnsignedFromMemory() => error: process is running", process_sp.get());
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
sb_error.SetErrorString("process is running");
}
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
{
sb_error.SetErrorString ("SBProcess is invalid");
}
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
return value;
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
}
lldb::addr_t
SBProcess::ReadPointerFromMemory (addr_t addr, lldb::SBError &sb_error)
{
lldb::addr_t ptr = LLDB_INVALID_ADDRESS;
lldb::SBTarget and lldb::SBProcess are now thread hardened. They both still contain shared pointers to the lldb_private::Target and lldb_private::Process objects respectively as we won't want the target or process just going away. Also cleaned up the lldb::SBModule to remove dangerous pointer accessors. For any code the public API files, we should always be grabbing shared pointers to any objects for the current class, and any other classes prior to running code with them. llvm-svn: 149238
2012-01-30 17:04:36 +08:00
ProcessSP process_sp(GetSP());
if (process_sp)
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
{
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
Process::StopLocker stop_locker;
if (stop_locker.TryLock(&process_sp->GetRunLock()))
{
Mutex::Locker api_locker (process_sp->GetTarget().GetAPIMutex());
ptr = process_sp->ReadPointerFromMemory (addr, sb_error.ref());
}
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_API));
Added logging when API calls try to do something that shouldn't be done when the process is stopped by having logging calls that end with "error: process is running". Also test for the process to be stopped when many SBValue API calls are made to make sure it is safe to evaluate values, children of values and much more. llvm-svn: 154160
2012-04-06 10:17:47 +08:00
if (log)
log->Printf ("SBProcess(%p)::ReadPointerFromMemory() => error: process is running", process_sp.get());
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
sb_error.SetErrorString("process is running");
}
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
{
sb_error.SetErrorString ("SBProcess is invalid");
}
return ptr;
}
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
size_t
SBProcess::WriteMemory (addr_t addr, const void *src, size_t src_len, SBError &sb_error)
{
size_t bytes_written = 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_API));
lldb::SBTarget and lldb::SBProcess are now thread hardened. They both still contain shared pointers to the lldb_private::Target and lldb_private::Process objects respectively as we won't want the target or process just going away. Also cleaned up the lldb::SBModule to remove dangerous pointer accessors. For any code the public API files, we should always be grabbing shared pointers to any objects for the current class, and any other classes prior to running code with them. llvm-svn: 149238
2012-01-30 17:04:36 +08:00
ProcessSP process_sp(GetSP());
Improved API logging. llvm-svn: 117772
2010-10-30 12:51:46 +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 ("SBProcess(%p)::WriteMemory (addr=0x%" PRIx64 ", src=%p, src_len=%" PRIu64 ", SBError (%p))...",
lldb::SBTarget and lldb::SBProcess are now thread hardened. They both still contain shared pointers to the lldb_private::Target and lldb_private::Process objects respectively as we won't want the target or process just going away. Also cleaned up the lldb::SBModule to remove dangerous pointer accessors. For any code the public API files, we should always be grabbing shared pointers to any objects for the current class, and any other classes prior to running code with them. llvm-svn: 149238
2012-01-30 17:04:36 +08:00
process_sp.get(),
Improved API logging. llvm-svn: 117772
2010-10-30 12:51:46 +08:00
addr,
src,
Stop using the "%z" size_t modifier and cast all size_t values to uint64_t. Some platforms don't support this modification. llvm-svn: 164148
2012-09-19 02:04:04 +08:00
(uint64_t)src_len,
Improved API logging. llvm-svn: 117772
2010-10-30 12:51:46 +08:00
sb_error.get());
}
lldb::SBTarget and lldb::SBProcess are now thread hardened. They both still contain shared pointers to the lldb_private::Target and lldb_private::Process objects respectively as we won't want the target or process just going away. Also cleaned up the lldb::SBModule to remove dangerous pointer accessors. For any code the public API files, we should always be grabbing shared pointers to any objects for the current class, and any other classes prior to running code with them. llvm-svn: 149238
2012-01-30 17:04:36 +08:00
if (process_sp)
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +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
Process::StopLocker stop_locker;
if (stop_locker.TryLock(&process_sp->GetRunLock()))
{
Mutex::Locker api_locker (process_sp->GetTarget().GetAPIMutex());
bytes_written = process_sp->WriteMemory (addr, src, src_len, sb_error.ref());
}
else
{
Added logging when API calls try to do something that shouldn't be done when the process is stopped by having logging calls that end with "error: process is running". Also test for the process to be stopped when many SBValue API calls are made to make sure it is safe to evaluate values, children of values and much more. llvm-svn: 154160
2012-04-06 10:17:47 +08:00
if (log)
log->Printf ("SBProcess(%p)::WriteMemory() => error: process is running", process_sp.get());
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
sb_error.SetErrorString("process is running");
}
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
Improved API logging. llvm-svn: 117772
2010-10-30 12:51:46 +08:00
if (log)
{
SBStream sstr;
sb_error.GetDescription (sstr);
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 ("SBProcess(%p)::WriteMemory (addr=0x%" PRIx64 ", src=%p, src_len=%" PRIu64 ", SBError (%p): %s) => %" PRIu64,
lldb::SBTarget and lldb::SBProcess are now thread hardened. They both still contain shared pointers to the lldb_private::Target and lldb_private::Process objects respectively as we won't want the target or process just going away. Also cleaned up the lldb::SBModule to remove dangerous pointer accessors. For any code the public API files, we should always be grabbing shared pointers to any objects for the current class, and any other classes prior to running code with them. llvm-svn: 149238
2012-01-30 17:04:36 +08:00
process_sp.get(),
Improved API logging. llvm-svn: 117772
2010-10-30 12:51:46 +08:00
addr,
src,
Stop using the "%z" size_t modifier and cast all size_t values to uint64_t. Some platforms don't support this modification. llvm-svn: 164148
2012-09-19 02:04:04 +08:00
(uint64_t)src_len,
Improved API logging. llvm-svn: 117772
2010-10-30 12:51:46 +08:00
sb_error.get(),
sstr.GetData(),
Stop using the "%z" size_t modifier and cast all size_t values to uint64_t. Some platforms don't support this modification. llvm-svn: 164148
2012-09-19 02:04:04 +08:00
(uint64_t)bytes_written);
Improved API logging. llvm-svn: 117772
2010-10-30 12:51:46 +08:00
}
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
return bytes_written;
}
Add GetDescription() and __repr__ () methods to most API classes, to allow "print" from inside Python to print out the objects in a more useful manner. llvm-svn: 114321
2010-09-20 13:20:02 +08:00
bool
SBProcess::GetDescription (SBStream &description)
{
<rdar://problem/10126482> Fixed an issues with the SBType and SBTypeMember classes: - Fixed SBType to be able to dump itself from python - Fixed SBType::GetNumberOfFields() to return the correct value for objective C interfaces - Fixed SBTypeMember to be able to dump itself from python - Fixed the SBTypeMember ability to get a field offset in bytes (the value being returned was wrong) - Added the SBTypeMember ability to get a field offset in bits Cleaned up a lot of the Stream usage in the SB API files. llvm-svn: 144493
2011-11-13 14:57:31 +08:00
Stream &strm = description.ref();
lldb::SBTarget and lldb::SBProcess are now thread hardened. They both still contain shared pointers to the lldb_private::Target and lldb_private::Process objects respectively as we won't want the target or process just going away. Also cleaned up the lldb::SBModule to remove dangerous pointer accessors. For any code the public API files, we should always be grabbing shared pointers to any objects for the current class, and any other classes prior to running code with them. llvm-svn: 149238
2012-01-30 17:04:36 +08:00
ProcessSP process_sp(GetSP());
if (process_sp)
Add GetDescription() and __repr__ () methods to most API classes, to allow "print" from inside Python to print out the objects in a more useful manner. llvm-svn: 114321
2010-09-20 13:20:02 +08:00
{
char path[PATH_MAX];
GetTarget().GetExecutable().GetPath (path, sizeof(path));
lldb::SBTarget and lldb::SBProcess are now thread hardened. They both still contain shared pointers to the lldb_private::Target and lldb_private::Process objects respectively as we won't want the target or process just going away. Also cleaned up the lldb::SBModule to remove dangerous pointer accessors. For any code the public API files, we should always be grabbing shared pointers to any objects for the current class, and any other classes prior to running code with them. llvm-svn: 149238
2012-01-30 17:04:36 +08:00
Module *exe_module = process_sp->GetTarget().GetExecutableModulePointer();
Added the ability to get the disassembly instructions from the function and symbol. llvm-svn: 115734
2010-10-06 11:09:58 +08:00
const char *exe_name = NULL;
if (exe_module)
exe_name = exe_module->GetFileSpec().GetFilename().AsCString();
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 ("SBProcess: pid = %" PRIu64 ", state = %s, threads = %d%s%s",
lldb::SBTarget and lldb::SBProcess are now thread hardened. They both still contain shared pointers to the lldb_private::Target and lldb_private::Process objects respectively as we won't want the target or process just going away. Also cleaned up the lldb::SBModule to remove dangerous pointer accessors. For any code the public API files, we should always be grabbing shared pointers to any objects for the current class, and any other classes prior to running code with them. llvm-svn: 149238
2012-01-30 17:04:36 +08:00
process_sp->GetID(),
<rdar://problem/10126482> Fixed an issues with the SBType and SBTypeMember classes: - Fixed SBType to be able to dump itself from python - Fixed SBType::GetNumberOfFields() to return the correct value for objective C interfaces - Fixed SBTypeMember to be able to dump itself from python - Fixed the SBTypeMember ability to get a field offset in bytes (the value being returned was wrong) - Added the SBTypeMember ability to get a field offset in bits Cleaned up a lot of the Stream usage in the SB API files. llvm-svn: 144493
2011-11-13 14:57:31 +08:00
lldb_private::StateAsCString (GetState()),
GetNumThreads(),
exe_name ? ", executable = " : "",
exe_name ? exe_name : "");
Add GetDescription() and __repr__ () methods to most API classes, to allow "print" from inside Python to print out the objects in a more useful manner. llvm-svn: 114321
2010-09-20 13:20:02 +08:00
}
else
<rdar://problem/10126482> Fixed an issues with the SBType and SBTypeMember classes: - Fixed SBType to be able to dump itself from python - Fixed SBType::GetNumberOfFields() to return the correct value for objective C interfaces - Fixed SBTypeMember to be able to dump itself from python - Fixed the SBTypeMember ability to get a field offset in bytes (the value being returned was wrong) - Added the SBTypeMember ability to get a field offset in bits Cleaned up a lot of the Stream usage in the SB API files. llvm-svn: 144493
2011-11-13 14:57:31 +08:00
strm.PutCString ("No value");
Add GetDescription() and __repr__ () methods to most API classes, to allow "print" from inside Python to print out the objects in a more useful manner. llvm-svn: 114321
2010-09-20 13:20:02 +08:00
return true;
}
Added support for loading and unloading shared libraries. This was done by adding support into lldb_private::Process: virtual uint32_t lldb_private::Process::LoadImage (const FileSpec &image_spec, Error &error); virtual Error lldb_private::Process::UnloadImage (uint32_t image_token); There is a default implementation that should work for both linux and MacOSX. This ability has also been exported through the SBProcess API: uint32_t lldb::SBProcess::LoadImage (lldb::SBFileSpec &image_spec, lldb::SBError &error); lldb::SBError lldb::SBProcess::UnloadImage (uint32_t image_token); Modified the DynamicLoader plug-in interface to require it to be able to tell us if it is currently possible to load/unload a shared library: virtual lldb_private::Error DynamicLoader::CanLoadImage () = 0; This way the dynamic loader plug-ins are allows to veto whether we can currently load a shared library since the dynamic loader might know if it is currenlty loading/unloading shared libraries. It might also know about the current host system and know where to check to make sure runtime or malloc locks are currently being held. Modified the expression parser to have ClangUserExpression::Evaluate() be the one that causes the dynamic checkers to be loaded instead of other code that shouldn't have to worry about it. llvm-svn: 118227
2010-11-04 09:54:29 +08:00
Add SBProcess::GetNumSupportedHardwareWatchpoints() API and export it through the Python scripting bridge. Add/modify some test cases. llvm-svn: 157353
2012-05-24 06:34:34 +08:00
uint32_t
SBProcess::GetNumSupportedHardwareWatchpoints (lldb::SBError &sb_error) const
{
<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_API));
Add SBProcess::GetNumSupportedHardwareWatchpoints() API and export it through the Python scripting bridge. Add/modify some test cases. llvm-svn: 157353
2012-05-24 06:34:34 +08:00
uint32_t num = 0;
ProcessSP process_sp(GetSP());
if (process_sp)
{
Mutex::Locker api_locker (process_sp->GetTarget().GetAPIMutex());
sb_error.SetError(process_sp->GetWatchpointSupportInfo (num));
if (log)
log->Printf ("SBProcess(%p)::GetNumSupportedHardwareWatchpoints () => %u",
process_sp.get(), num);
}
else
{
sb_error.SetErrorString ("SBProcess is invalid");
}
return num;
}
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
uint32_t
SBProcess::LoadImage (lldb::SBFileSpec &sb_image_spec, lldb::SBError &sb_error)
{
lldb::SBTarget and lldb::SBProcess are now thread hardened. They both still contain shared pointers to the lldb_private::Target and lldb_private::Process objects respectively as we won't want the target or process just going away. Also cleaned up the lldb::SBModule to remove dangerous pointer accessors. For any code the public API files, we should always be grabbing shared pointers to any objects for the current class, and any other classes prior to running code with them. llvm-svn: 149238
2012-01-30 17:04:36 +08:00
ProcessSP process_sp(GetSP());
if (process_sp)
The LLDB API (lldb::SB*) is now thread safe! llvm-svn: 122262
2010-12-21 04:49:23 +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
Process::StopLocker stop_locker;
if (stop_locker.TryLock(&process_sp->GetRunLock()))
{
Mutex::Locker api_locker (process_sp->GetTarget().GetAPIMutex());
return process_sp->LoadImage (*sb_image_spec, sb_error.ref());
}
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_API));
Added logging when API calls try to do something that shouldn't be done when the process is stopped by having logging calls that end with "error: process is running". Also test for the process to be stopped when many SBValue API calls are made to make sure it is safe to evaluate values, children of values and much more. llvm-svn: 154160
2012-04-06 10:17:47 +08:00
if (log)
log->Printf ("SBProcess(%p)::LoadImage() => error: process is running", process_sp.get());
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
sb_error.SetErrorString("process is running");
}
The LLDB API (lldb::SB*) is now thread safe! llvm-svn: 122262
2010-12-21 04:49:23 +08:00
}
Added support for loading and unloading shared libraries. This was done by adding support into lldb_private::Process: virtual uint32_t lldb_private::Process::LoadImage (const FileSpec &image_spec, Error &error); virtual Error lldb_private::Process::UnloadImage (uint32_t image_token); There is a default implementation that should work for both linux and MacOSX. This ability has also been exported through the SBProcess API: uint32_t lldb::SBProcess::LoadImage (lldb::SBFileSpec &image_spec, lldb::SBError &error); lldb::SBError lldb::SBProcess::UnloadImage (uint32_t image_token); Modified the DynamicLoader plug-in interface to require it to be able to tell us if it is currently possible to load/unload a shared library: virtual lldb_private::Error DynamicLoader::CanLoadImage () = 0; This way the dynamic loader plug-ins are allows to veto whether we can currently load a shared library since the dynamic loader might know if it is currenlty loading/unloading shared libraries. It might also know about the current host system and know where to check to make sure runtime or malloc locks are currently being held. Modified the expression parser to have ClangUserExpression::Evaluate() be the one that causes the dynamic checkers to be loaded instead of other code that shouldn't have to worry about it. llvm-svn: 118227
2010-11-04 09:54:29 +08:00
return LLDB_INVALID_IMAGE_TOKEN;
}
lldb::SBError
SBProcess::UnloadImage (uint32_t image_token)
{
lldb::SBError sb_error;
lldb::SBTarget and lldb::SBProcess are now thread hardened. They both still contain shared pointers to the lldb_private::Target and lldb_private::Process objects respectively as we won't want the target or process just going away. Also cleaned up the lldb::SBModule to remove dangerous pointer accessors. For any code the public API files, we should always be grabbing shared pointers to any objects for the current class, and any other classes prior to running code with them. llvm-svn: 149238
2012-01-30 17:04:36 +08:00
ProcessSP process_sp(GetSP());
if (process_sp)
The LLDB API (lldb::SB*) is now thread safe! llvm-svn: 122262
2010-12-21 04:49:23 +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
Process::StopLocker stop_locker;
if (stop_locker.TryLock(&process_sp->GetRunLock()))
{
Mutex::Locker api_locker (process_sp->GetTarget().GetAPIMutex());
sb_error.SetError (process_sp->UnloadImage (image_token));
}
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_API));
Added logging when API calls try to do something that shouldn't be done when the process is stopped by having logging calls that end with "error: process is running". Also test for the process to be stopped when many SBValue API calls are made to make sure it is safe to evaluate values, children of values and much more. llvm-svn: 154160
2012-04-06 10:17:47 +08:00
if (log)
log->Printf ("SBProcess(%p)::UnloadImage() => error: process is running", process_sp.get());
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
sb_error.SetErrorString("process is running");
}
The LLDB API (lldb::SB*) is now thread safe! llvm-svn: 122262
2010-12-21 04:49:23 +08:00
}
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
else
sb_error.SetErrorString("invalid process");
return sb_error;
}