Update TODO

TODO

@@ -70,17 +70,15 @@ Before 1.2:
 
 * If interrupt happens in kernel mode, send both
   kernel stack and user space stack, have userspace stitch them
-  together. (User space stack must probably be done in a thread - kernel 
-  stack must probably be taken in the interrupt itself?
-  - Why this difference? The page tables should still be loaded. Is it
-    because pages_present() doesn't work? No, turning it off doesn't help.
-  - It looks like this works. Get:
-
-       struct pt_regs *user_regs =
-          (void *)current->thread.esp0 - sizeof (struct pt_regs);
-
-    then use pages_present as usual to trace with user_regs; There could be
-    rare lockups though.
+  together. well, they could be stitched together in the kernel. 
+	Already done: we now take a stacktrace of the user space process
+	when the interrupt happens in kernel mode. We don't take any
+	stacktraces of the kernel though. Things that need to be investigated:
+		- does the kernel come with dwarf debug information?
+		- does the kernel come with some other debug info
+		- is there a place where the vmlinux binary is usually
+		  placed? (We should avoid any "location of vmlinux" type
+		  questions if at all possible).
 
 * Correctness
 	- When the module is unloaded, kill all processes blocking in read
@@ -450,6 +448,18 @@ Later:
 
 DONE:
 
+* (User space stack must probably be done in a thread - kernel 
+  stack must probably be taken in the interrupt itself?
+  - Why this difference? The page tables should still be loaded. Is it
+    because pages_present() doesn't work? No, turning it off doesn't help.
+  - It looks like this works. Get:
+
+       struct pt_regs *user_regs =
+          (void *)current->thread.esp0 - sizeof (struct pt_regs);
+
+    then use pages_present as usual to trace with user_regs; There could be
+    rare lockups though.
+
 * Non-GUI version that can save in a format the GUI can understand.
   Could be used for profiling startup etc. Would preferably be able to
   dump the data to a network socket. Should be able to react to eg.

signal-handler.c

@@ -54,6 +54,10 @@ lookup_signal_watch (int signo)
     return NULL;
 }
 
+/* These two functions might be interrupted by a signal handler that is
+ * going to run lookup_signal_watch(). Assuming that pointer writes are
+ * atomic, the code below should be ok.
+ */
 static void
 add_signal_watch (SignalWatch *watch)
 {