SuibianP wrote:
The FIFO file served two purposes,
- Send real target PID back to debugger
- Synchronisation: Prevent premature execution of target
And the original implementation 0f0462c states the reason against socket and
signal,
> I'm using this instead of using a signal or a similar mechanism because I
> don't want the launcher program to wait indefinitely to be attached in case
> the debugger crashed. That would pollute the process list with a lot of
> hanging processes.
> I preferred not to use sockets because it requires a lot of code and I only
> need a pid. It would also require a lot of code when windows support is
> implemented.
I took a step back and feel that this is probably doable without elaborate
IPCs. Below is what I am thinking of (haven't actually tried yet).
1. Always create a new process in suspension (`SIGSTOP`/`CREATE_SUSPENDED`)
2. Send the PID back to debugger
- POSIX, send signal and debugger can read `si_pid`
- Dead launcher: timed `sigsuspend` with `alarm` (Darwin does not have
`sigtimedwait`)
- Dead debugger: `waitid(WNOHANG | WCONTINUED)` after timeout
- Windows, use `PostThreadMessage` with `GetMessage`
- Dead launcher: `MsgWaitForMultipleObjects`
- Dead debugger: `CheckRemoteDebuggerPresent` after timeout
3. Attach to process and resume as normal
There would still be platform-specific code, but presumably still less clutter
than FIFO/socket.
Any comments @ashgti @walter-erquinigo?
https://github.com/llvm/llvm-project/pull/121269
_______________________________________________
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
