aboutsummaryrefslogtreecommitdiff
path: root/lldb/unittests/Process/ProcessEventDataTest.cpp
AgeCommit message (Collapse)AuthorFilesLines
2021-01-25Fix -Wmissing-override in lldbDavid Blaikie1-7/+7
2021-01-25[ThreadPlan] fix exec on LinuxWalter Erquinigo1-2/+2
2020-12-12[lldb] "target create" shouldn't save target if the command failedTatyana Krasnukha1-6/+1
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-02[lldb] Treat remote macOS debugging like any other remote darwin platformJonas Devlieghere1-2/+3
Extract remote debugging logic from PlatformMacOSX and move it into PlatformRemoteMacOSX so it can benefit from all the logic necessary for remote debugging. Until now, remote macOS debugging was treated almost identical to local macOS debugging. By moving in into its own class, we can have it inherit from PlatformRemoteDarwinDevice and all the functionality it provides, such as looking at the correct DeviceSupport directory. rdar://68167374 Differential revision: https://reviews.llvm.org/D92452
2020-06-11[lldb] Check if thread was suspended during previous stop added.Ilya Bukonkin1-0/+256
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