Just to clarify my use of "interrupted". Of course all threads should be stopped upon SBProcess::Stop(). However, upon SBProcess:Resume() I/O operations shouldn't just return due to the SIGSTOP but continue doing what they did before receiving the signal.
Thanks, Mario On Sun, Oct 26, 2014 at 11:56 AM, Mario Zechner <badlogicga...@gmail.com> wrote: > Hi, > > i'm currently trying to understand how LLDB interrupts/resumes processes. > To my understanding, the Process implementation sends a SIGSTOP to the > inferior, which will stop the process. Alternatively, the process may be > stopped (e.g. breakpoint) while Process::DoHalt is executing, in which case > the event is marked as interrupted. I have a few questions regarding this: > > 1) How can i check wether an event was marked as interrupted via the API? > SBProcess has a couple of static methods like GetStateFromEvent, but none > of these allow me to check if the event was marked as interrupted > 2) SIGSTOP seems to interrupt any I/O call, e.g. getchar, listen, and so > on. Upon a resume, these functions will simply return (e.g. returning EOF) > instead of continuing waiting for input. Is there any way to have this not > happen? > > Our problem is, that we need to stop/resume the process to implement parts > of JDWP (Java debugging wire protocol). Some JDWP commands require us to > stop the process, read some memory regions and resume the process again, > letting the inferior think that nothing has happened. All of this should > not interfere with normal program execution, e.g. a file read shouldn't be > interrupted because we stopped the inferior via SBProcess:Stop(). > > As always, thanks for all your help! > > ciao, > Mario >
_______________________________________________ lldb-dev mailing list lldb-dev@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
