| #
4fdb5863 |
| 21-Oct-2013 |
Jason Molenda <[email protected]> |
Expose the Thread::GetQueueID() method through the SBThread API, similar to the existing SBThread::GetQueueName() method.
llvm-svn: 193132
|
| #
f86248d9 |
| 12-Sep-2013 |
Richard Mitton <[email protected]> |
Added a 'jump' command, similar to GDBs.
This allows the PC to be directly changed to a different line. It's similar to the example python script in examples/python/jump.py, except implemented as a
Added a 'jump' command, similar to GDBs.
This allows the PC to be directly changed to a different line. It's similar to the example python script in examples/python/jump.py, except implemented as a builtin.
Also this version will track the current function correctly even if the target line resolves to multiple addresses. (e.g. debugging a templated function)
llvm-svn: 190572
show more ...
|
| #
4d56e9c1 |
| 18-Jul-2013 |
Jim Ingham <[email protected]> |
This commit does two things. One, it converts the return value of the QueueThreadPlanXXX plan providers from a "ThreadPlan *" to a "lldb::ThreadPlanSP". That was needed to fix a bug where the Thre
This commit does two things. One, it converts the return value of the QueueThreadPlanXXX plan providers from a "ThreadPlan *" to a "lldb::ThreadPlanSP". That was needed to fix a bug where the ThreadPlanStepInRange wasn't checking with its sub-plans to make sure they succeed before trying to proceed further. If the sub-plan failed and as a result didn't make any progress, you could end up retrying the same failing algorithm in an infinite loop.
<rdar://problem/14043602>
llvm-svn: 186618
show more ...
|
|
Revision tags: llvmorg-3.3.1-rc1, llvmorg-3.3.0, llvmorg-3.3.0-rc3, llvmorg-3.3.0-rc2, llvmorg-3.3.0-rc1 |
|
| #
a75418db |
| 15-Apr-2013 |
Andrew Kaylor <[email protected]> |
Adding new Python API function to check for stopped threads.
llvm-svn: 179577
|
| #
5160ce5c |
| 27-Mar-2013 |
Greg Clayton <[email protected]> |
<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 logg
<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
show more ...
|
| #
0a2df227 |
| 28-Feb-2013 |
Enrico Granata <[email protected]> |
the log entry for SBThread::GetProcess() would not include the pointer to the process because we were using the value of the (otherwise unused) process_sp - instead of fetching the SP from sb_process
the log entry for SBThread::GetProcess() would not include the pointer to the process because we were using the value of the (otherwise unused) process_sp - instead of fetching the SP from sb_process
llvm-svn: 176231
show more ...
|
| #
f85defae |
| 20-Dec-2012 |
Andrew Kaylor <[email protected]> |
Adding eStopReasonThreadExiting and fixing the handling of this state on Linux.
llvm-svn: 170800
|
|
Revision tags: llvmorg-3.2.0 |
|
| #
c627682e |
| 12-Dec-2012 |
Jim Ingham <[email protected]> |
Fixed a few bugs in the "step in" thread plan logic. Added a "step-in-target" flag to "thread step-in" so if you have something like:
Process 28464 stopped * thread #1: tid = 0x1c03, function: main
Fixed a few bugs in the "step in" thread plan logic. Added a "step-in-target" flag to "thread step-in" so if you have something like:
Process 28464 stopped * thread #1: tid = 0x1c03, function: main , stop reason = breakpoint 1.1 frame #0: 0x0000000100000e08 a.out`main at main.c:62 61 -> 62 int A6 = complex (a(4), b(5), c(6)); // Stop here to step targetting b and hitting breakpoint. 63
and you want to get into "complex" skipping a, b and c, you can do:
(lldb) step -t complex Process 28464 stopped * thread #1: tid = 0x1c03, function: complex , stop reason = step in frame #0: 0x0000000100000d0d a.out`complex at main.c:44 41 42 int complex (int first, int second, int third) 43 { -> 44 return first + second + third; // Step in targetting complex should stop here 45 } 46 47 int main (int argc, char const *argv[])
llvm-svn: 170008
show more ...
|
|
Revision tags: llvmorg-3.2.0-rc3 |
|
| #
93a64300 |
| 05-Dec-2012 |
Daniel Malea <[email protected]> |
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)
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
show more ...
|
| #
90ba8115 |
| 05-Dec-2012 |
Greg Clayton <[email protected]> |
<rdar://problem/12649160>
Added the ability to debug through your process exec'ing itself to the same architecture.
llvm-svn: 169340
|
|
Revision tags: llvmorg-3.2.0-rc2 |
|
| #
d01b2953 |
| 29-Nov-2012 |
Daniel Malea <[email protected]> |
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
|
|
Revision tags: llvmorg-3.2.0-rc1 |
|
| #
4f465cff |
| 10-Oct-2012 |
Jim Ingham <[email protected]> |
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,
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>
llvm-svn: 165640
show more ...
|
| #
97d5cf05 |
| 25-Sep-2012 |
Greg Clayton <[email protected]> |
<rdar://problem/9959501>
More KDP debugging process. We can not set breakpoints, hit them, resume, step and detach while running.
llvm-svn: 164584
|
| #
6fe2dc79 |
| 14-Sep-2012 |
Jim Ingham <[email protected]> |
Remove a duplicate frame_sp local that was shadowing the one we copied the incoming SBFrame into.
<rdar://problem/12304255>
llvm-svn: 163943
|
| #
94b09246 |
| 14-Sep-2012 |
Jim Ingham <[email protected]> |
SBThread::StepOut and SBThread::StepOutOfFrame should both run all threads.
llvm-svn: 163938
|
| #
c02e3344 |
| 14-Sep-2012 |
Jim Ingham <[email protected]> |
SBThread::StepOverUntil should run all threads. It is running to breakpoints, so running one thread is likely to cause the target to stall.
llvm-svn: 163924
|
| #
cb640dd8 |
| 14-Sep-2012 |
Jim Ingham <[email protected]> |
Make the unwinding of the stack part of "thread return" work, and add the thread return command.
llvm-svn: 163867
|
| #
4413758c |
| 12-Sep-2012 |
Jim Ingham <[email protected]> |
Start at getting "thread return" working. Doesn't work yet.
llvm-svn: 163670
|
| #
4fc6cb9c |
| 22-Aug-2012 |
Jim Ingham <[email protected]> |
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
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
show more ...
|
|
Revision tags: llvmorg-3.1.0 |
|
| #
7ba6e991 |
| 11-May-2012 |
Jim Ingham <[email protected]> |
Found one more place where the OkayToDiscard needs to be consulted. Also changed the defaults for SBThread::Step* to not delete extant plans. Also added some test cases to test more complex stepping
Found one more place where the OkayToDiscard needs to be consulted. Also changed the defaults for SBThread::Step* to not delete extant plans. Also added some test cases to test more complex stepping scenarios.
llvm-svn: 156667
show more ...
|
|
Revision tags: llvmorg-3.1.0-rc3 |
|
| #
64e7ead1 |
| 03-May-2012 |
Jim Ingham <[email protected]> |
Clean up the usage of "MasterPlan" status in ThreadPlans. Only user-initiated plans should be MasterPlans that want to stay on the plan stack. So make all plans NOT MasterPlans by default and then
Clean up the usage of "MasterPlan" status in ThreadPlans. Only user-initiated plans should be MasterPlans that want to stay on the plan stack. So make all plans NOT MasterPlans by default and then have the SB API's and the CommandObjectThread step commands set this explicitly.
Also added a "clean up" phase to the Thread::ShouldStop so that if plans get stranded on the stack, we can remove them. This is done by adding an IsPlanStale method to the thread plans, and if the plan can know that it is no longer relevant, it returns true, and the plan and its sub-plans will get discarded.
llvm-svn: 156101
show more ...
|
|
Revision tags: llvmorg-3.1.0-rc2, llvmorg-3.1.0-rc1 |
|
| #
c9858e4d |
| 06-Apr-2012 |
Greg Clayton <[email protected]> |
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
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
show more ...
|
| #
7fdf9ef1 |
| 05-Apr-2012 |
Greg Clayton <[email protected]> |
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 n
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
show more ...
|
| #
31950a53 |
| 28-Mar-2012 |
Greg Clayton <[email protected]> |
Fixed some space formatting.
llvm-svn: 153582
|
| #
e72dfb32 |
| 24-Feb-2012 |
Greg Clayton <[email protected]> |
<rdar://problem/10103468>
I started work on being able to add symbol files after a debug session had started with a new "target symfile add" command and quickly ran into problems with stale Address
<rdar://problem/10103468>
I started work on being able to add symbol files after a debug session had started with a new "target symfile add" command and quickly ran into problems with stale Address objects in breakpoint locations that had lldb_private::Section pointers into modules that had been removed or replaced. This also let to grabbing stale modules from those sections. So I needed to thread harded the Address, Section and related objects.
To do this I modified the ModuleChild class to now require a ModuleSP on initialization so that a weak reference can created. I also changed all places that were handing out "Section *" to have them hand out SectionSP. All ObjectFile, SymbolFile and SymbolVendors were inheriting from ModuleChild so all of the find plug-in, static creation function and constructors now require ModuleSP references instead of Module *.
Address objects now have weak references to their sections which can safely go stale when a module gets destructed.
This checkin doesn't complete the "target symfile add" command, but it does get us a lot clioser to being able to do such things without a high risk of crashing or memory corruption.
llvm-svn: 151336
show more ...
|