From patchwork Thu Feb 4 16:58:26 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Yao Qi X-Patchwork-Id: 10732 Received: (qmail 36948 invoked by alias); 4 Feb 2016 16:58:36 -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 36936 invoked by uid 89); 4 Feb 2016 16:58:35 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.6 required=5.0 tests=AWL, BAYES_00, FREEMAIL_FROM, RCVD_IN_DNSWL_LOW, SPF_PASS autolearn=ham version=3.3.2 spammy=engaged, Antoine, 2015-11, 201511 X-HELO: mail-pf0-f181.google.com Received: from mail-pf0-f181.google.com (HELO mail-pf0-f181.google.com) (209.85.192.181) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Thu, 04 Feb 2016 16:58:34 +0000 Received: by mail-pf0-f181.google.com with SMTP id o185so50545925pfb.1 for ; Thu, 04 Feb 2016 08:58:34 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version:content-type :content-transfer-encoding; bh=YRXV0o7NuEqImA4OQJrRPID5xVWYQm8caDuCHwNwnEg=; b=bZ6duzpR0pZ/qGwOJIotmBTvu5vPaYPq9zjWs2+vDxG3+Cg1xs/Ke+aJ3tWIe19v9X Od+/IGTFLCX/jgv1NgNJiHBq94nQxaCuYO5F2neuS3pDBSIbqNfi2UkWyENhPq/KG51x f0U5qv19tp7UmAJN2QyWF1U2hM/nzB+VtpHQkGkYhZ3Xi8kSJD+sfzSXYt3Kbrrrugbs ufQqZzkYTZhqj21SsgG7M6bMnqWiBhxrBc2p5fS5zSa5PoCyLHQna6PYthEj2OMvOZNz Cq4F4vhC34ukUJCzoN1vIJJ23ugwruUfNn8wJmVn8UttLckxhfbm+cTrEni9ObnxyMZV 0jGA== X-Gm-Message-State: AG10YOQrmDOo/ZucwOnangfW7FBkznbyp6c0UEjpGPYK8z2y3ZIi9qjalvBWU15gqo1kFA== X-Received: by 10.66.220.170 with SMTP id px10mr12431406pac.145.1454605112641; Thu, 04 Feb 2016 08:58:32 -0800 (PST) Received: from E107787-LIN (gcc1-power7.osuosl.org. [140.211.15.137]) by smtp.gmail.com with ESMTPSA id b63sm18448296pfj.25.2016.02.04.08.58.29 (version=TLS1_2 cipher=AES128-SHA bits=128/128); Thu, 04 Feb 2016 08:58:31 -0800 (PST) From: Yao Qi To: Antoine Tremblay Cc: Yao Qi , Pedro Alves , , Subject: Re: Move threads out of jumppad without single step References: <86zixzvhj1.fsf@gmail.com> <565C6043.4040106@redhat.com> <864mg2v1s5.fsf@gmail.com> <56A8F4AE.5040305@ericsson.com> <56ABCEFF.4090506@ericsson.com> Date: Thu, 04 Feb 2016 16:58:26 +0000 In-Reply-To: <56ABCEFF.4090506@ericsson.com> (Antoine Tremblay's message of "Fri, 29 Jan 2016 15:43:43 -0500") Message-ID: <86si18o1jh.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 X-IsSubscribed: yes Antoine Tremblay writes: > I've tested this in all stop/non stop and it works properly. > > Basically what happens is that if stabilize_threads is not called in > the context of linux_resume and that gdbserver needs to report an > event, it won't since last_resume_kind can be resume_stop. > > In the current case gdbserver is in cmd_qtdp, the last command was > continue (vCont;c) in all stop mode so last_resume_kind is > resume_stop. > > So when going in linux_wait, the event is filtered out by : > event_thread = (struct thread_info *) > find_inferior (&all_threads, status_pending_p_callback, &filter_ptid); > > Since status_pending_p_callback returns false. > > Note that this fix may not the best one... but it may be some progress... > > Any ideas are welcome, otherwise I will add it to my patch set and > there can be more discussion at review. Hi Antoine, I don't have an idea to your problem and your fix, but I don't understand why don't we see this problem before. I may miss some details of your problem, so please include these details in your patches. What I want to say here is that we still need more tests and works to get software single step properly/fully engaged with the rest part of GDBserver before we introduce (fast) tracepoint for ARM into GDBserver. The software single step in GDBserver isn't fully exercised yet, for example, GDB still doesn't emit vCont;s and vCont;S to ask GDBserver to do single step on arm-linux. If we force GDB to emit vCont;s on arm-linux, as the patch below does, there are still some problems, 1. PTRACE_SINGLESTEP is used in ptrace call in GDBserver, which is obviously wrong, 2. PC increment is still incorrect if the single step is requested by GDB. We've had a fix https://sourceware.org/ml/gdb-patches/2015-11/msg00470.html to fix the PC increment when if single step is requested by GDBserver itself. I did some fixes but there are still some work to do software single step in GDBserver requested by GDB. I don't want to block your fast tracepoint work, just raise these issues, and let you know my thoughts. diff --git a/gdb/arm-linux-tdep.c b/gdb/arm-linux-tdep.c index 3421f3b..dead2b9 100644 --- a/gdb/arm-linux-tdep.c +++ b/gdb/arm-linux-tdep.c @@ -935,11 +935,6 @@ arm_linux_software_single_step (struct frame_info *frame) VEC (CORE_ADDR) *next_pcs = NULL; struct cleanup *old_chain = make_cleanup (VEC_cleanup (CORE_ADDR), &next_pcs); - /* If the target does have hardware single step, GDB doesn't have - to bother software single step. */ - if (target_can_do_single_step () == 1) - return 0; - arm_get_next_pcs_ctor (&next_pcs_ctx, &arm_linux_get_next_pcs_ops, gdbarch_byte_order (gdbarch), diff --git a/gdb/gdbserver/server.c b/gdb/gdbserver/server.c index ef715e7..0d51dec 100644 --- a/gdb/gdbserver/server.c +++ b/gdb/gdbserver/server.c @@ -2958,12 +2958,15 @@ handle_v_requests (char *own_buf, int packet_len, int *new_packet_len) { strcpy (own_buf, "vCont;c;C;t"); - if (target_supports_hardware_single_step () || !vCont_supported) + if (target_supports_hardware_single_step () + || target_supports_software_single_step () + || !vCont_supported) { - /* If target supports hardware single step, add actions s - and S to the list of supported actions. On the other - hand, if GDB doesn't request the supported vCont actions - in qSupported packet, add s and S to the list too. */ + /* If target supports single step either by hardware or by + software, add actions s and S to the list of supported + actions. On the other hand, if GDB doesn't request the + supported vCont actions in qSupported packet, add s and + S to the list too. */ own_buf = own_buf + strlen (own_buf); strcpy (own_buf, ";s;S"); } diff --git a/gdb/infrun.c b/gdb/infrun.c index 15210c9..3e2d76e 100644 --- a/gdb/infrun.c +++ b/gdb/infrun.c @@ -2246,6 +2246,11 @@ maybe_software_singlestep (struct gdbarch *gdbarch, CORE_ADDR pc) { int hw_step = 1; + /* If the target does have hardware single step, GDB doesn't have + to bother software single step. */ + if (target_can_do_single_step () == 1) + return 1; + if (execution_direction == EXEC_FORWARD && gdbarch_software_single_step_p (gdbarch) && gdbarch_software_single_step (gdbarch, get_current_frame ()))