[Lldb-commits] [lldb] [lldb] Allow forks to occur in expression evaluation (PR #184815)

[via lldb-commits]

================
@@ -6045,11 +6045,27 @@ CommandObject *ProcessGDBRemote::GetPluginCommandObject() {
   return m_command_sp.get();
 }
 
-void ProcessGDBRemote::DidForkSwitchSoftwareBreakpoints(bool enable) {
-  GetBreakpointSiteList().ForEach([this, enable](BreakpointSite *bp_site) {
+void ProcessGDBRemote::DidForkSwitchSoftwareBreakpoints(
+    bool enable, bool is_expression_fork) {
+  Log *log = GetLog(GDBRLog::Process);
+  bool is_expr = !enable && is_expression_fork;
+
+  GetBreakpointSiteList().ForEach([this, enable, is_expr,
+                                   log](BreakpointSite *bp_site) {
     if (bp_site->IsEnabled() &&
         (bp_site->GetType() == BreakpointSite::eSoftware ||
          bp_site->GetType() == BreakpointSite::eExternal)) {
+      // During expression evaluation, retain internal breakpoints (e.g. the
+      // _start return trap) in the forked child so it dies deterministically
+      // on SIGTRAP rather than executing _start with a corrupted stack.
+      if (is_expr && bp_site->IsInternal()) {
----------------
jimingham wrote:

This isn't quite enough.  There are lots of other internal breakpoints you do want to remove.  lldb uses breakpoints for stepping and if you were in the middle of a stepping operation that had gotten suspended for some reason, there might be step breakpoints in code the child side of the fork might execute.  You don't want to leave those in place.  There are also breakpoints in the loader, for instance, though it seems unlikely that code on the child side of a fork tries to load libraries between the fork completing and the exec...

ThreadPlanCallFunction determines the "end of function call" breakpoint using:

`Target::GetEntryPointAddress() 
`
So you can compare the site address against this.  Might be nice not to do this raw but have a way to ask ThreadPlanCallFunction what address it was planning to use for this purpose rather than having to duplicate that logic here.

https://github.com/llvm/llvm-project/pull/184815