mgorny added a comment. In D98822#2658252 <https://reviews.llvm.org/D98822#2658252>, @labath wrote:
> In D98822#2646052 <https://reviews.llvm.org/D98822#2646052>, @mgorny wrote: > >> It includes refactoring clone/fork/vfork event monitoring into a single >> function. Right now, only forks are supported — the handler creates a local >> `NativeProcessLinux` instance (@labath, any suggestions how to make this >> less hacky?), duplicates parent's breakpoints into it (just like the child >> gets parent's memory) and uses it to clear these breakpoints and detach the >> child process. > > I don't find this particularly hacky. However, I have doubts about the > breakpoint clearing aspect. If we add that now, I think it will be tricky to > move that process to the client in the future (how will the client know > whether the breakpoints were auto-removed?) Given that breakpoints in forked > process have been borked since forever, I don't see harm in keeping that > broken for a little while longer. Even a client with extremely limited of > multiple processes (like the one we had in mind) should not have a problem > with sending the appropriate `z` packets before it detaches. This patch could > still come first (it's great that you've separated that out) -- it just needs > to ensure that there are no breakpoints in the child path which would need > clearing. Actually, that's not a problem at all. If client doesn't indicate `fork-events` support via `qSupported`, we handle breakpoints server-side. If it does, we deliver `fork` stop reason and then the client is responsible for dealing with breakpoints. > Btw, have you by any chance looked at how gdb determines which clone()s > constitute a new thread? If I read the code correctly, GDB always assumes `PTRACE_EVENT_CLONE` is a new thread, and does not support spawning processes via it. CHANGES SINCE LAST ACTION https://reviews.llvm.org/D98822/new/ https://reviews.llvm.org/D98822 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits