delta/llvm.git/lldb/source/Target/ThreadPlanStack.cpp, branch main

[lldb] Remove unneeded .get() NFC

2023-01-05T06:05:40+00:00

Revert "[lldb] Remove redundant .c_str() and .get() calls"

2022-12-19T08:52:10+00:00

This reverts commit fbaf48be0ff6fb24b9aa8fe9c2284fe88a8798dd.

This has broken all LLDB buildbots:
https://lab.llvm.org/buildbot/#/builders/68/builds/44990
https://lab.llvm.org/buildbot/#/builders/96/builds/33160

[lldb] Remove redundant .c_str() and .get() calls

2022-12-18T01:15:25+00:00

Removing .c_str() has a semantics difference, but the use scenarios
likely do not matter as we don't have NUL in the strings.

Add a mutex to the ThreadPlanStackMap class.

2022-04-29T18:07:22+00:00

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

Remove redundant return and continue statements (NFC)

2021-12-25T07:17:54+00:00

Identified with readability-redundant-control-flow.

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

2021-11-11T21:04:44+00:00

[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

[lldb] Avoid moving ThreadPlanSP from plans vector

2021-08-01T17:40:04+00:00

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

Add a mutex to guard access to the ThreadPlanStack class

2021-07-16T22:40:58+00:00

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

[lldb] Rename QueueFundamentalPlan to QueueBasePlan (NFC)

2021-03-05T05:46:49+00:00

Minor change for naming consistency.

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

[lldb] Remove unused ThreadPlan tracer utilities (NFC)

2021-02-16T01:59:25+00:00

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