This reapplies #195858 with a fix for 32-bit arm (and generally, any
architecture that uses software single-stepping). The problem was that
the temporary breakpoints used for single-stepping were interfering with
the breakpoints set by the client.
The fix is to check for existing breakpoints before setting the
temporary ones. To achieve this, I've separated the notion of "next PC
candidates for a thread" from "step breakpoints we've actually set".
The freebsd code had some software single stepping code, but:
- this was [introduced](https://reviews.llvm.org/D95802) for mips64
support, which was
[removed](https://github.com/llvm/llvm-project/pull/179582) earlier this
year
- AFAICT, this never worked since the original patch only checked
`m_threads_stepping_with_breakpoint`, but never set it to anything.
This is why I'm removing the remnants of the single step support instead
of trying to adapt it.
The original commit message was:
We did not say so explictly, but I'd argue that via
https://github.com/llvm/llvm-project/pull/195815, we are supporting
stubs which do not refcount breakpoints. In these stubs the set/clear
breakpoint packets are idempotent:
- setting a breakpoint for the second time is a no-op (returns OK)
- clearing a breakpoint clears it, regardless of how many times it has
been set
- clearing a non-existent breakpoint (either because it was already
cleared, or because it was never set) returns an error
This makes lldb-server one of those stubs, which makes the code slightly
simpler, but more importantly, ensures we do not regress this behavior.
Pavel Labath
26cae628b4