History log of /llvm-project-15.0.7/lldb/source/API/SBThread.cpp (Results 101 – 125 of 173)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
# 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 ...


1234567