[RFC] persistence of schedlock mode

[Michael Snyder <msnyder@vmware.com>]

[-- Attachment #1: Type: text/plain, Size: 487 bytes --]

Bug 11580 points out a problem related to persistence of the
scheduler locking mode.  If you set the mode to "on" (which
means that only one thread can run), and then kill and restart
your program, the mode persists and your program may deadlock.

I don't think this is a problem for mode "step", and it could
be argued that mode "on" is "use at your own risk".  However
I've been thinking about how to resolve it, and this simple
but intrusive patch is what I come up with.

Comments?


[-- Attachment #2: schedlock.txt --]
[-- Type: text/plain, Size: 1236 bytes --]

Index: infrun.c
===================================================================
RCS file: /cvs/src/src/gdb/infrun.c,v
retrieving revision 1.438
diff -u -p -r1.438 infrun.c
--- infrun.c	6 May 2010 19:14:08 -0000	1.438
+++ infrun.c	12 May 2010 17:37:09 -0000
@@ -1416,6 +1416,18 @@ set_schedlock_func (char *args, int from
     }
 }
 
+/* reset_schedlock -- public */
+ 
+void
+reset_schedlock ()
+{
+  if (scheduler_mode == schedlock_on)
+    {
+      warning ("Resetting scheduler-lock mode to 'off'");
+      scheduler_mode = schedlock_off;
+    }
+}
+
 /* True if execution commands resume all threads of all processes by
    default; otherwise, resume only threads of the current inferior
    process.  */
Index: target.c
===================================================================
RCS file: /cvs/src/src/gdb/target.c,v
retrieving revision 1.250
diff -u -p -r1.250 target.c
--- target.c	6 May 2010 22:29:49 -0000	1.250
+++ target.c	12 May 2010 17:37:09 -0000
@@ -2231,6 +2231,10 @@ void
 target_mourn_inferior (void)
 {
   struct target_ops *t;
+
+  /* Clear schedlock in infrun.c */
+  reset_schedlock ();
+
   for (t = current_target.beneath; t != NULL; t = t->beneath)
     {
       if (t->to_mourn_inferior != NULL)