| 4e75e3533bddc7cf7264c6c7f7b4d812d4466e96 |
|
07-May-2013 |
Andrew Kaylor <andrew.kaylor@intel.com> |
Reinstating r181091 and r181106 with fix for Linux regressions.
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@181340 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/Target/OperatingSystem.h
|
| 95bea1dfb166a1816ee36a3453aa3ebeca248844 |
|
07-May-2013 |
Ashok Thirumurthi <ashok.thirumurthi@intel.com> |
Temporarily reverting r181091 and r181106 due to the vast test breakage on the Linux buildbots
while we develop a better understanding of how to manage the thread lists in a platform-independant fashion.
Reviewed by: Daniel Malea
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@181323 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/Target/OperatingSystem.h
|
| 7bee8abf1678cb4dade06add9036981f7249ba09 |
|
04-May-2013 |
Greg Clayton <gclayton@apple.com> |
After recent OperatingsSystem plug-in changes, the lldb_private::Process and lldb_private::Thread subclasses were changed and the API was not respected properly.
This checkin aims to fix this. The process now has two thread lists: a real thread list for threads that are created by the lldb_private::Process subclass, and the user visible threads. The user visible threads are the same as the real threas when no OS plug-in in used. But when an OS plug-in is used, the user thread can be a combination of real and "memory" threads. Real threads can be placed inside of memory threads so that a thread appears to be different, but is still controlled by the actual real thread. When the thread list needs updating, the lldb_private::Process class will call the: lldb_private::Process::UpdateThreadList() function with the old real thread list, and the function is expected to fill in the new real thread list with the current state of the process. After this function, the process will check if there is an OS plug-in being used, and if so, it will give the old user thread list, the new real thread list and the OS plug-in will create the new user thread list from both of these lists. If there is no OS plug-in, the real thread list is the user thread list.
These changes keep the lldb_private::Process subclasses clean and no changes are required.
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@181091 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/Target/OperatingSystem.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/include/lldb/Target/OperatingSystem.h
|
| 52ebc0aab1fdecb634801deceeddd71a14c2148c |
|
19-Jan-2013 |
Greg Clayton <gclayton@apple.com> |
<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.
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@172873 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/Target/OperatingSystem.h
|
| 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/include/lldb/Target/OperatingSystem.h
|
| ae932359b80098532f3c3766fa9e6527352fbb67 |
|
10-Apr-2012 |
Greg Clayton <gclayton@apple.com> |
Trying to solve our disappearing thread issues by making thread list updates safer.
The current ProcessGDBRemote function that updates the threads could end up with an empty list if any other thread had the sequence mutex. We now don't clear the thread list when we can't access it, and we also have changed how lldb_private::Process handles the return code from the:
virtual bool
Process::UpdateThreadList (lldb_private::ThreadList &old_thread_list,
lldb_private::ThreadList &new_thread_list) = 0;
A bool is now returned to indicate if the list was actually updated or not and the lldb_private::Process class will only update the stop ID of the validity of the thread list if "true" is returned.
The ProcessGDBRemote also got an extra assertion that will hopefully assert when running debug builds so we can find the source of this issue.
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@154365 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/Target/OperatingSystem.h
|
| 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/include/lldb/Target/OperatingSystem.h
|