[lldb][tests] Automatically call compute_mydir (NFC)Eliminate boilerplate of having each test manually assign to `mydir` by calling`compute_mydir` in lldbtest.py.Differential Revision: https://r
[lldb][tests] Automatically call compute_mydir (NFC)Eliminate boilerplate of having each test manually assign to `mydir` by calling`compute_mydir` in lldbtest.py.Differential Revision: https://reviews.llvm.org/D128077
show more ...
[LLDB] Fix TestJobControl.py decorators import
[LLDB] Skip TestJobControl.py AArch64/Arm LinuxTestJobControl.py is randomly failing on AArch64/Arm Linux buildbots.I am marking it as skipped to make buildbot stable.
[lldb/driver] Fix SIGTSTP handlingOur SIGTSTP handler was working, but that was mostly accidental.The reason it worked is because lldb is multithreaded for most of itslifetime and the OS is reas
[lldb/driver] Fix SIGTSTP handlingOur SIGTSTP handler was working, but that was mostly accidental.The reason it worked is because lldb is multithreaded for most of itslifetime and the OS is reasonably fast at responding to signals. So,what happened was that the kill(SIGTSTP) which we sent from inside thehandler was delivered to another thread while the handler was still setto SIG_DFL (which then correctly put the entire process to sleep).Sometimes it happened that the other thread got the second signal afterthe first thread had already restored the handler, in which case thesignal handler would run again, and it would again attempt to send theSIGTSTP signal back to itself.Normally it didn't take many iterations for the signal to be deliveredquickly enough. However, if you were unlucky (or were playing aroundwith pexpect) you could get SIGTSTP while lldb was single-threaded, andin that case, lldb would go into an endless loop because the secondSIGTSTP could only be handled on the main thread, and only after thehandler for the first signal returned (and re-installed itself). In thatsituation the handler would keep re-sending the signal to itself.This patch fixes the issue by implementing the handler the way itsupposed to be done:- before sending the second SIGTSTP, we unblock the signal (it gets automatically blocked upon entering the handler)- we use raise to send the signal, which makes sure it gets delivered to the thread which is running the handlerThis also means we don't need the SIGCONT handler, as our TSTP handlerresumes right after the entire process is continued, and we can do therequired work there.I also include a test case for the SIGTSTP flow. It uses pexpect, but itincludes a couple of extra twists. Specifically, I needed to create anextra process on top of lldb, which will run lldb in a separate processgroup and simulate the role of the shell. This is needed because SIGTSTPis not effective on a session leader (the signal gets delivered, but itdoes not cause a stop) -- normally there isn't anyone to notice thestop.Differential Revision: https://reviews.llvm.org/D120320