mgorny added a comment.
In D128932#3631903 <https://reviews.llvm.org/D128932#3631903>, @labath wrote:
> I have a feeling the semaphores will not work (compile) on darwin. I didn't
> find any sem_init call there -- just sem_open. Maybe instead of semaphores we
> could use files for the synchronization? Something similar to the
> `wait_for_file_on_target` function, just in the other direction. Then the
> test could create a file to move the processes forward? (This might be easier
> to achieve with a dedicated inferior, instead of trying to fit it into the
> universal LLGS inferior.)
Damn, and I thought POSIX actually means something to Darwin. Yeah, I'll look
into using some other synchronization mechanism.
================
Comment at:
lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.cpp:1110
// does not interfere with our protocol.
- StopSTDIOForwarding();
+ if (!m_non_stop)
+ StopSTDIOForwarding();
----------------
labath wrote:
> In the multiprocess all-stop mode, if one process stops, we are supposed to
> stop all of them, right? I take it that's not something we do right now, is
> it?
We don't support resuming multiple processes in all-stop mode. `vCont` returns
an error if you try to do that, and other continue packets are blocking, so it
can't happen ;-).
================
Comment at: lldb/test/API/tools/lldb-server/TestGdbRemoteForkNonStop.py:116
+ parent_pid, parent_tid, child_pid, child_tid = (
+ self.start_fork_test(["fork", "sleep:2", "print-pid", "sleep:2",
+ "stop"],
----------------
labath wrote:
> mgorny wrote:
> > mgorny wrote:
> > > I really dislike these sleeps but I can't think of a better way of doing
> > > it (short of using IPC for synchronization). The goal is to 1) ensure
> > > that both processes start before they start outputting, and 2) ensure
> > > that both output before the first stop reason comes.
> > Ok, semaphores are not scary after all, and I suppose we can expect them to
> > work if we expect `fork()` to work.
> > ensure that both processes start before they start outputting
> But we should be able to see the output from the first process (if it had
> any) even it is the only process running. Do we have a test for that? Could
> you add a step where the first process outputs something before it waits to
> synchronize with the second process?
Yes, I suppose covering that with a test also makes sense.
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D128932/new/
https://reviews.llvm.org/D128932
_______________________________________________
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
