From c7a78e9c5783d5ed03ca7ea4c2b56ed113689b90 Mon Sep 17 00:00:00 2001 From: Tim Newsome Date: Mon, 20 May 2019 14:16:07 -0700 Subject: 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 | 18 +++++++++++++++++- 1 file changed, 17 insertions(+), 1 deletion(-) (limited to 'src/server') diff --git a/src/server/gdb_server.c b/src/server/gdb_server.c index 48b312a..c9c8aae 100644 --- a/src/server/gdb_server.c +++ b/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); -- cgit v1.1