Introduce three new stop reasons for fork, vfork and vforkdone events.
This includes server support for serializing fork/vfork events into
gdb-remote protocol. The stop infos for the two base events take a pair
of PID and TID for the newly forked process.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
For other readers: as discussed in D100191, I've stripped client part of this (except for trivial enumerations). The server part will be used in tests but the stop reasons won't be reported to regular clients as they don't report fork-events support.
lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.cpp | ||
---|---|---|
946–948 | I just realized this is implicitly assuming the multiprocess extension is enabled/supported. That makes sense since forking always involves multiple processes, though maybe the server should check that the client actually reports it as supported. |
lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.cpp | ||
---|---|---|
946–948 | Makes sense. I'll add it to the extension patch since that's where we determine if fork/vfork is supported. |
Add an assert to make sure that process doesn't report fork/vfork stop reason without multiprocess support.
I guess this is the reason for that..
What I meant here was to do a sanity check on the client extensions -- like if a client claims to support "vfork-events" but not "multiprocess", then its probably broken (though it's a question what we should actually do about that). In the server our gdb-remote class always (I hope) supports multiprocess, so there's no danger of inconsistency.
I just realized this is implicitly assuming the multiprocess extension is enabled/supported. That makes sense since forking always involves multiple processes, though maybe the server should check that the client actually reports it as supported.