History log of /external/lldb/source/Plugins/Process/mach-core/ThreadMachCore.h
Revision Date Author Comments (<<< Hide modified files) (Show modified files >>>)
863aa28adf536c9c008e1590f25da662431d6f13 09-May-2013 Greg Clayton <gclayton@apple.com> Changed the formerly pure virtual function:

namespace lldb_private {
class Thread
{
virtual lldb::StopInfoSP
GetPrivateStopReason() = 0;
};
}

To not be virtual. The lldb_private::Thread now handles the correct caching and will call a new pure virtual function:

namespace lldb_private {
class Thread
{
virtual bool
CalculateStopInfo() = 0;
}
}

This function must be overridden by thead lldb_private::Thread subclass and the only thing it needs to do is to set the Thread::StopInfo() with the current stop reason and return true, or return false if there is no stop reason. The lldb_private::Thread class will take care of calling this function only when it is required. This allows lldb_private::Thread subclasses to be a bit simpler and not all need to duplicate the cache and invalidation settings.

Also renamed:

lldb::StopInfoSP
lldb_private::Thread::GetPrivateStopReason();

To:

lldb::StopInfoSP
lldb_private::Thread::GetPrivateStopInfo();

Also cleaned up a case where the ThreadPlanStepOverBreakpoint might not re-set its breakpoint if the thread disappears (which was happening due to a bug when using the OperatingSystem plug-ins with memory threads and real threads).



git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@181501 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/Process/mach-core/ThreadMachCore.h
a46013bde54626b68cd2013b108f73a205f4b29a 01-May-2013 Greg Clayton <gclayton@apple.com> <rdar://problem/13700260>
<rdar://problem/13723772>

Modified the lldb_private::Thread to work much better with the OperatingSystem plug-ins. Operating system plug-ins can now return have a "core" key/value pair in each thread dictionary for the OperatingSystemPython plug-ins which allows the core threads to be contained with memory threads. It also allows these memory threads to be stepped, resumed, and controlled just as if they were the actual backing threads themselves.

A few things are introduced:
- lldb_private::Thread now has a GetProtocolID() method which returns the thread protocol ID for a given thread. The protocol ID (Thread::GetProtocolID()) is usually the same as the thread id (Thread::GetID()), but it can differ when a memory thread has its own id, but is backed by an actual API thread.
- Cleaned up the Thread::WillResume() code to do the mandatory parts in Thread::ShouldResume(), and let the thread subclasses override the Thread::WillResume() which is now just a notification.
- Cleaned up ClearStackFrames() implementations so that fewer thread subclasses needed to override them
- Changed the POSIXThread class a bit since it overrode Thread::WillResume(). It is doing the wrong thing by calling "Thread::SetResumeState()" on its own, this shouldn't be done by thread subclasses, but the current code might rely on it so I left it in with a TODO comment with an explanation.



git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@180886 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/Process/mach-core/ThreadMachCore.h
94a5d0de4433dce556db59758f3d6124eb0e1a2a 10-Oct-2012 Jim Ingham <jingham@apple.com> Change the Thread constructor over to take a Process& rather than a ProcessSP. We can't create Threads with a NULL ProcessSP, so it makes no sense to use the SP.
Then make the Thread a Broadcaster, and get it to broadcast when the selected frame is changed (but only from the Command Line) and when Thread::ReturnFromFrame
changes the stack.
Made the Driver use this notification to print the new thread status rather than doing it in the command.
Fixed a few places where people were setting their broadcaster class by hand rather than using the static broadcaster class call.

<rdar://problem/12383087>


git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@165640 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/Process/mach-core/ThreadMachCore.h
f4124deeb9532044a38c0774ced872f2709347da 21-Feb-2012 Greg Clayton <gclayton@apple.com> Thread hardening part 3. Now lldb_private::Thread objects have std::weak_ptr
objects for the backlink to the lldb_private::Process. The issues we were
running into before was someone was holding onto a shared pointer to a
lldb_private::Thread for too long, and the lldb_private::Process parent object
would get destroyed and the lldb_private::Thread had a "Process &m_process"
member which would just treat whatever memory that used to be a Process as a
valid Process. This was mostly happening for lldb_private::StackFrame objects
that had a member like "Thread &m_thread". So this completes the internal
strong/weak changes.

Documented the ExecutionContext and ExecutionContextRef classes so that our
LLDB developers can understand when and where to use ExecutionContext and
ExecutionContextRef objects.



git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@151009 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/Process/mach-core/ThreadMachCore.h
37b416669bb9316d73081403e6e26ed0e09526ba 10-Feb-2012 Greg Clayton <gclayton@apple.com> Fixed incorrect #include directives.



git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@150271 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/Process/mach-core/ThreadMachCore.h
46c9a355af9b39db78c006b2a5cbf97d3c58d947 09-Feb-2012 Greg Clayton <gclayton@apple.com> First pass at mach-o core file support is in. It currently works for x86_64
user space programs. The core file support is implemented by making a process
plug-in that will dress up the threads and stack frames by using the core file
memory.

Added many default implementations for the lldb_private::Process functions so
that plug-ins like the ProcessMachCore don't need to override many many
functions only to have to return an error.

Added new virtual functions to the ObjectFile class for extracting the frozen
thread states that might be stored in object files. The default implementations
return no thread information, but any platforms that support core files that
contain frozen thread states (like mach-o) can make a module using the core
file and then extract the information. The object files can enumerate the
threads and also provide the register state for each thread. Since each object
file knows how the thread registers are stored, they are responsible for
creating a suitable register context that can be used by the core file threads.

Changed the process CreateInstace callbacks to return a shared pointer and
to also take an "const FileSpec *core_file" parameter to allow for core file
support. This will also allow for lldb_private::Process subclasses to be made
that could load crash logs. This should be possible on darwin where the crash
logs contain all of the stack frames for all of the threads, yet the crash
logs only contain the registers for the crashed thrad. It should also allow
some variables to be viewed for the thread that crashed.



git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@150154 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/Process/mach-core/ThreadMachCore.h