From patchwork Mon Apr 23 21:51:48 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Joel Brobecker X-Patchwork-Id: 26912 Received: (qmail 76544 invoked by alias); 23 Apr 2018 21:51:55 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Delivered-To: mailing list gdb-patches@sourceware.org Received: (qmail 76529 invoked by uid 89); 23 Apr 2018 21:51:53 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-24.9 required=5.0 tests=AWL, BAYES_00, GIT_PATCH_0, GIT_PATCH_1, GIT_PATCH_2, GIT_PATCH_3, RCVD_IN_DNSWL_NONE, SPF_PASS autolearn=ham version=3.3.2 spammy=beneath, unconditionally, from_tty, Hx-languages-length:3494 X-HELO: rock.gnat.com Received: from rock.gnat.com (HELO rock.gnat.com) (205.232.38.15) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 23 Apr 2018 21:51:51 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id 65ECA116259 for ; Mon, 23 Apr 2018 17:51:50 -0400 (EDT) Received: from rock.gnat.com ([127.0.0.1]) by localhost (rock.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id jZ9VsZL5qB65 for ; Mon, 23 Apr 2018 17:51:50 -0400 (EDT) Received: from tron.gnat.com (tron.gnat.com [205.232.38.10]) by rock.gnat.com (Postfix) with ESMTP id 575021161F4 for ; Mon, 23 Apr 2018 17:51:50 -0400 (EDT) Received: by tron.gnat.com (Postfix, from userid 4233) id 5372354C; Mon, 23 Apr 2018 17:51:50 -0400 (EDT) From: Joel Brobecker To: gdb-patches@sourceware.org Subject: [RFA] (Ada/ravenscar) error during "continue" after task/thread switch Date: Mon, 23 Apr 2018 17:51:48 -0400 Message-Id: <1524520308-85149-1-git-send-email-brobecker@adacore.com> Hello, 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): + swtich 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 maching 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, knowning 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. OK to push? Thank you! diff --git a/gdb/top.c b/gdb/top.c index 8903a92..0480726 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 unless 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); }