Add a mutex to the ThreadPlanStackMap class.
We've seen very occasional crashes that we can only explain by
simultaneous access to the ThreadPlanStackMap, so I'm adding a
mutex to protect it.

Differ

Add a mutex to the ThreadPlanStackMap class.
We've seen very occasional crashes that we can only explain by
simultaneous access to the ThreadPlanStackMap, so I'm adding a
mutex to protect it.

Differential Revision: https://reviews.llvm.org/D124029

show more ...

Remove redundant return and continue statements (NFC)

Identified with readability-redundant-control-flow.

[lldb][NFC] Inclusive Language: rename master plan to controlling plan

[NFC] As part of using inclusive language within the llvm project, this patch
renames master plan to controlling plan in lldb.

[lldb][NFC] Inclusive Language: rename master plan to controlling plan

[NFC] As part of using inclusive language within the llvm project, this patch
renames master plan to controlling plan in lldb.

Reviewed By: jingham

Differential Revision: https://reviews.llvm.org/D113019

show more ...

[lldb] Avoid moving ThreadPlanSP from plans vector

Change `ThreadPlanStack::PopPlan` and `::DiscardPlan` to not do the following:

1. Move the last plan, leaving a moved `ThreadPlanSP` in the plans

[lldb] Avoid moving ThreadPlanSP from plans vector

Change `ThreadPlanStack::PopPlan` and `::DiscardPlan` to not do the following:

1. Move the last plan, leaving a moved `ThreadPlanSP` in the plans vector
2. Operate on the last plan
3. Pop the last plan off the plans vector

This leaves a period of time where the last element in the plans vector has been moved. I am not sure what, if any, guarantees there are when doing this, but it seems like it would/could leave a null `ThreadPlanSP` in the container. There are asserts in place to prevent empty/null `ThreadPlanSP` instances from being pushed on to the stack, and so this could break that invariant during multithreaded access to the thread plan stack.

An open question is whether this use of `std::move` was the result of a measure performance problem.

Differential Revision: https://reviews.llvm.org/D106171

show more ...

Add a mutex to guard access to the ThreadPlanStack class

We've seen reports of crashes (none we've been able to reproduce
locally) that look like they are caused by concurrent access to a
thread pla

Add a mutex to guard access to the ThreadPlanStack class

We've seen reports of crashes (none we've been able to reproduce
locally) that look like they are caused by concurrent access to a
thread plan stack. It looks like there are error paths when an
interrupt request to debugserver times out that cause this problem.

The thread plan stack access is never in a hot loop, and there
aren't enough of them for the extra data member to matter, so
there's really no good reason not to protect the access.

Adding the mutex revealed a couple of places where we were
using "auto" in an iteration when we should have been using
"auto &" - we didn't intend to copy the stack - and I fixed
those as well.

Except for preventing crashes this should be NFC.

Differential Revision: https\://reviews.llvm.org/D106122

show more ...

[lldb] Rename QueueFundamentalPlan to QueueBasePlan (NFC)

Minor change for naming consistency.

Differential Revision: https://reviews.llvm.org/D97985

[lldb] Remove unused ThreadPlan tracer utilities (NFC)

Delete unused `EnableTracer()` and `SetTracer()` functions on `Thread`. By deleting
these, their `ThreadPlan` counterparts also become unused.

[lldb] Remove unused ThreadPlan tracer utilities (NFC)

Delete unused `EnableTracer()` and `SetTracer()` functions on `Thread`. By deleting
these, their `ThreadPlan` counterparts also become unused.

Then, by deleting `ThreadPlanStack::EnableTracer`, `EnableSingleStep` becomes unused.
With no more callers to `EnableSingleStep`, the value `m_single_step` is always true and
can be removed as well.

Differential Revision: https://reviews.llvm.org/D96666

show more ...

[lldb] Remove unused ThreadPlanStack::GetStackOfKind (NFC)

This function isn't used.

Differential Revision: https://reviews.llvm.org/D95411

[ThreadPlan] fix exec on Linux

[lldb] Fix -Wparentheses in ThreadPlanStack.cpp

Don't access reference to a vector after pop_back

This is undefined behavior. Found by asan's detect_container_overflow.

Fix unused variable, format, and format string warnings.
NFC.

Allow the ThreadPlanStackMap to hold the thread plans for threads
that were not reported by the OS plugin. To facilitate this, move
adding/updating the ThreadPlans for a Thread to the ThreadPlanStac

Allow the ThreadPlanStackMap to hold the thread plans for threads
that were not reported by the OS plugin. To facilitate this, move
adding/updating the ThreadPlans for a Thread to the ThreadPlanStackMap.
Also move dumping thread plans there as well.

Added some tests for "thread plan list" and "thread plan discard" since
I didn't seem to have written any originally.

Differential Revision: https://reviews.llvm.org/D76814

show more ...

Move thread plan stacks into the Process, indexed by TID.

Differential Revision: https://reviews.llvm.org/D75880