labath added a subscriber: mgorny. labath added a comment. The general idea makes sense, as we don't stop for forks even during normal execution. I'll too defer to @jingham on the implementation.
I am also wondering what is the current and expected behavior in the `follow-fork=child` mode. The user probably did not intend to follow the expression into the child process (and the thread plan will definitely get completely confused), but I'm also not sure that overriding the user setting is the right thing to do. In D129521#3644244 <https://reviews.llvm.org/D129521#3644244>, @yinghuitan wrote: > I do wonder if there will be more unexpected signals (like SIGCHILD, SIGPIPE > etc...) causing expression evaluation to pause? Should we maybe default to > not stop on signals? I think that's a different (and more complicated) discussion, and probably not relevant here. The default disposition of SIGCHLD is already set to `no-stop`, and if the user deliberately changed it, I wouldn't want to override it. ================ Comment at: lldb/test/API/commands/expression/fork/TestForkExprs.py:17-19 + def setUp(self): + # Call super's setUp(). + TestBase.setUp(self) ---------------- unused code. ================ Comment at: lldb/test/API/commands/expression/fork/TestForkExprs.py:21 + + @skipUnlessPlatform(["linux"]) + def test_more_expr_commands(self): ---------------- Technically, I think this should pass on all systems that have the fork function (i.e. they are not windows), even if we don't support fork tracking there. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D129521/new/ https://reviews.llvm.org/D129521 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
