| 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/Utility/ThreadMemory.cpp
|
| 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/Utility/ThreadMemory.cpp
|
| 5042acfb254338f60ef8bc3a8715e229795d941f |
|
20-Apr-2013 |
Greg Clayton <gclayton@apple.com> |
<rdar://problem/13697881>
Fixed the GDB remote with the python OS plug-in to not show core threads when they aren't desired and also to have the threads "to the right thing" when continuing.
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@179912 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/Process/Utility/ThreadMemory.cpp
|
| 9acf3699d2bea583b45c762f4cd82b2a4af6131b |
|
12-Apr-2013 |
Greg Clayton <gclayton@apple.com> |
<rdar://problem/13491977>
Made some fixes to the OperatingSystemPython class:
- If any thread dictionary contains any "core=N" key/value pairs then the threads obtained from the lldb_private::Process itself will be placed inside the ThreadMemory threads and will be used to get the information for a thread.
- Cleaned up all the places where a thread inside a thread was causing problems
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@179405 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/Process/Utility/ThreadMemory.cpp
|
| 836064ad50d20992275e3647aba2fb0cb0fc571e |
|
08-Jan-2013 |
Greg Clayton <gclayton@apple.com> |
<rdar://problem/12586010>
Python OS plug-ins now fetch thread registers lazily.
Also changed SBCommandInterpreter::HandleCommand() to not take the API lock. The logic here is that from the command line you can execute a command that might result in another thread (like the private process thread) to execute python or run any code that can re-enter the public API. When this happens, a deadlock immediately occurs for things like "process launch" and "process attach".
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@171901 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/Process/Utility/ThreadMemory.cpp
|
| 91a9f2127fa8b8e90f6ea1676d11f97f44ce22dd |
|
25-Oct-2012 |
Greg Clayton <gclayton@apple.com> |
Allow operating system plug-ins to specify the address for registers so we don't have to create data up front.
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@166701 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/Process/Utility/ThreadMemory.cpp
|
| 6bc24c10080b624a2782e6e42f683e5d65c6903c |
|
16-Oct-2012 |
Jim Ingham <jingham@apple.com> |
Patch from Matt Kopec <matt.kopec@intel.com> to fix the problem that if two breakpoints were set on consecutive addresses, the continue from the
first breakpoint would skip the second.
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@166000 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/Process/Utility/ThreadMemory.cpp
|
| 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/Utility/ThreadMemory.cpp
|
| b8f126a807c00e5c2d0e7faaf764c38072cd6764 |
|
24-Aug-2012 |
Greg Clayton <gclayton@apple.com> |
The OS plug-in can now get data from a python script that implements the protocol.
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@162540 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/Process/Utility/ThreadMemory.cpp
|
| 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/Utility/ThreadMemory.cpp
|
| 37f962e785be99dc4f0c5e9d02416992ff03bbd0 |
|
22-Aug-2011 |
Greg Clayton <gclayton@apple.com> |
Added a new plug-in type: lldb_private::OperatingSystem. The operating system
plug-ins are add on plug-ins for the lldb_private::Process class that can add
thread contexts that are read from memory. It is common in kernels to have
a lot of threads that are not currently executing on any cores (JTAG debugging
also follows this sort of thing) and are context switched out whose state is
stored in memory data structures. Clients can now subclass the OperatingSystem
plug-ins and then make sure their Create functions correcltly only enable
themselves when the right binary/target triple are being debugged. The
operating system plug-ins get a chance to attach themselves to processes just
after launching or attaching and are given a lldb_private::Process object
pointer which can be inspected to see if the main executable, target triple,
or any shared libraries match a case where the OS plug-in should be used.
Currently the OS plug-ins can create new threads, define the register contexts
for these threads (which can all be different if desired), and populate and
manage the thread info (stop reason, registers in the register context) as
the debug session goes on.
git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@138228 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/Process/Utility/ThreadMemory.cpp
|