[lldb] Return StringRef from PluginInterface::GetPluginNameThere is no reason why this function should be returning a ConstString.While modifying these files, I also fixed several instances where
[lldb] Return StringRef from PluginInterface::GetPluginNameThere is no reason why this function should be returning a ConstString.While modifying these files, I also fixed several instances whereGetPluginName and GetPluginNameStatic were returning different strings.I am not changing the return type of GetPluginNameStatic in this patch, as thatwould necessitate additional changes, and this patch is big enough as it is.Differential Revision: https://reviews.llvm.org/D111877
show more ...
[lldb] Remove PluginInterface::GetPluginVersionIn all these years, we haven't found a use for this function (it haszero callers). Lets just remove the boilerplate.Differential Revision: https://
[lldb] Remove PluginInterface::GetPluginVersionIn all these years, we haven't found a use for this function (it haszero callers). Lets just remove the boilerplate.Differential Revision: https://reviews.llvm.org/D109600
Fix -Wmissing-override in lldb
[ThreadPlan] fix exec on Linux
[lldb] "target create" shouldn't save target if the command failedTargetList::CreateTarget automatically adds created target to the list, however,CommandObjectTargetCreate does some additional pre
[lldb] "target create" shouldn't save target if the command failedTargetList::CreateTarget automatically adds created target to the list, however,CommandObjectTargetCreate does some additional preparation after creating a targetand which can fail. The command should remove created target if it failed. Sincethe 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
[lldb/Test] Fix unittest nameLit looks for the Tests prefix in the unit test name.
[lldb] Check if thread was suspended during previous stop added.Encountered the following situation: Let we started thread T1 and it hitbreakpoint on B1 location. We suspended T1 and continued the
[lldb] Check if thread was suspended during previous stop added.Encountered the following situation: Let we started thread T1 and it hitbreakpoint 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 returningfalse.Expected result: process continues (as if T2 did not hit breakpoint) itsworkflow with T1 still suspended. Actual result: process do stops (as ifT2 callback returned true).Solution: We need invalidate StopInfo for threads that was previouslysuspended just because something that is already inactive can not be thereason of stop. Thread::GetPrivateStopInfo() may be appropriate place todo it, because it gets called (through Thread::GetStopInfo()) every timebefore process reports stop and user gets chance to changem_resume_state again i.e if we see m_resume_state == eStateSuspendedit definitely means it was set during previous stop and it also meansthis thread can not be stopped again (cos' it was frozen duringprevious stop).Differential revision: https://reviews.llvm.org/D80112