Commit Graph

6 Commits

Author SHA1 Message Date
Pavel Labath a3939e159f [lldb] Return StringRef from PluginInterface::GetPluginName
There is no reason why this function should be returning a ConstString.

While modifying these files, I also fixed several instances where
GetPluginName and GetPluginNameStatic were returning different strings.

I am not changing the return type of GetPluginNameStatic in this patch, as that
would necessitate additional changes, and this patch is big enough as it is.

Differential Revision: https://reviews.llvm.org/D111877
2021-10-18 10:14:42 +02:00
Pavel Labath b03126768a [lldb] Remove PluginInterface::GetPluginVersion
In all these years, we haven't found a use for this function (it has
zero callers). Lets just remove the boilerplate.

Differential Revision: https://reviews.llvm.org/D109600
2021-09-13 10:29:00 +02:00
David Blaikie 6846686128 Fix -Wmissing-override in lldb 2021-01-25 15:04:21 -08:00
Walter Erquinigo 4bb6244871 [ThreadPlan] fix exec on Linux 2021-01-25 11:30:48 -08:00
Tatyana Krasnukha 2634ec6ce9 [lldb] "target create" shouldn't save target if the command failed
TargetList::CreateTarget automatically adds created target to the list, however,
CommandObjectTargetCreate does some additional preparation after creating a target
and which can fail. The command should remove created target if it failed. Since
the function has many ways to return, scope guard does this work safely.

Changes to the TargetList make target adding and selection more transparent.

Other changes remove unnecessary SetSelectedTarget after CreateTarget.

Differential Revision: https://reviews.llvm.org/D93052
2020-12-12 16:40:58 +03:00
Ilya Bukonkin 3b43f00629 [lldb] Check if thread was suspended during previous stop added.
Encountered the following situation: Let we started thread T1 and it hit
breakpoint on B1 location. We suspended T1 and continued the process.
Then we started thread T2 which hit for example the same location B1.
This time in a breakpoint callback we decided not to stop returning
false.

Expected result: process continues (as if T2 did not hit breakpoint) its
workflow with T1 still suspended. Actual result: process do stops (as if
T2 callback returned true).

Solution: We need invalidate StopInfo for threads that was previously
suspended just because something that is already inactive can not be the
reason of stop. Thread::GetPrivateStopInfo() may be appropriate place to
do it, because it gets called (through Thread::GetStopInfo()) every time
before process reports stop and user gets chance to change
m_resume_state again i.e if we see m_resume_state == eStateSuspended
it definitely means it was set during previous stop and it also means
this thread can not be stopped again (cos' it was frozen during
previous stop).

Differential revision: https://reviews.llvm.org/D80112
2020-06-11 15:02:46 -07:00