From 0ca1fc291305ee1701b8236c0e26e8d8c5eaf0a2 Mon Sep 17 00:00:00 2001 From: Joel Brobecker Date: Mon, 30 Apr 2018 17:05:42 -0500 Subject: [PATCH] [Ada/ravenscar] error during "continue" after task/thread switch When debugging a program using the Ada ravenscar profile, resuming a program's execution after having switched to a different task sometimes yields the following error: (gdb) cont Continuing. Cannot execute this command while the target is running. Use the "interrupt" command to stop the target and then try again. In short, the Ravenscar profile is a standardized subset of Ada which allows tasking (often mapped to threads). We often use it on baremetal targets where there is no OS support. Thread support is implemented as a thread target_ops layer. It sits on top of the "remote" layer, so we can do thread debugging against baremetal targets to which GDB is connected via "target remote". What happens, when the user request the program to resume execution, is the following: - the ravenscar-thread target_ops layer gets the order to resume the program's execution. The current thread is not the active thread in the inferior, and the "remote" layer doesn't know about that thread anyway. So what we do is (see ravenscar_resume): + switch inferior_ptid to the ptid of the actually active thread; + ask the layer beneath us to actually do the resume. - Once that's done, the resuming itself is done. But execute_command (in top.c) actually does a bit more. More precisely, it unconditionally checks to see if the language may no longer be matching the current frame: check_frame_language_change (); The problem, here, is that we haven't received the "stop" event from the inferior, yet. This part will be handled by the event loop, which is done later. So, checking for the language-change here doesn't make sense, since we don't really have a frame. In our case, the error comes from the fact that we end up trying to read the registers, which causes the error while the remote protocol is waiting for the event showing the inferior stopped. This apparently used to work, but it is believed that this was only accidental. In other words, we had enough information already cached within GDB that we were able to perform the entire call to check_frame_language_change without actually querying the target. On PowerPC targets, this started to fail as a side-effect of a minor change in the way we get to the regcache during the handling of software-single-step (which seems fine). This patch fixes the issue by only calling check_frame_language_change in cases the inferior isn't running. Otherwise, it skips it, knowing that the event loop should eventually get to it. gdb/ChangeLog: * top.c (execute_command): Do not call check_frame_language_change if the inferior is running. Tested on x86_64-linux, no regression. Also tested on aarch64-elf, arm-elf, leon3-elf, and ppc-elf, but using AdaCore's testsuite. --- gdb/top.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/gdb/top.c b/gdb/top.c index 8903a929834..d9d4639a1b6 100644 --- a/gdb/top.c +++ b/gdb/top.c @@ -642,7 +642,12 @@ execute_command (const char *p, int from_tty) } } - check_frame_language_change (); + /* Only perform the frame-language-change check if the command + we just finished executing did not resume the inferior's execution. + If it did resume the inferior, we will do that check after + the inferior stopped. */ + if (has_stack_frames () && !is_running (inferior_ptid)) + check_frame_language_change (); discard_cleanups (cleanup_if_error); } -- 2.30.2