Don't update RTOS threads just before step. (#376)

This messes up all kinds of tests against HiFive Unleashed, because some
harts may be single stepped from previous tests. The symptom is that gdb
will suddenly be accessing a different hart than you think it is.

I replaced it with a comment so I can remember what happened when time
comes to upstream this change. It may not be acceptable depending on
what the reason for the call is in the first place.

Change-Id: I1fb44d5a7792835f66342f590a5f7bbf8c21b64e

src/server/gdb_server.c

@@ -2784,7 +2784,23 @@ static bool gdb_handle_vcont_packet(struct connection *connection, const char *p
 
 			if (target->rtos != NULL) {
 				/* FIXME: why is this necessary? rtos state should be up-to-date here already! */
-				rtos_update_threads(target);
+
+				/* Sometimes this results in picking a different thread than
+				 * gdb just requested to step. Then we fake it, and now there's
+				 * a different thread selected than gdb expects, so register
+				 * accesses go to the wrong one!
+				 * E.g.:
+				 * Hg1$
+				 * P8=72101ce197869329$		# write r8 on thread 1
+				 * g$
+				 * vCont?$
+				 * vCont;s:1;c$				# rtos_update_threads changes to other thread
+				 * g$
+				 * qXfer:threads:read::0,fff$
+				 * P8=cc060607eb89ca7f$		# write r8 on other thread
+				 * g$
+				 * */
+				/* rtos_update_threads(target); */
 
 				target->rtos->gdb_target_for_threadid(connection, thread_id, &ct);