From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 98282 invoked by alias); 4 Feb 2016 18:24:05 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 98131 invoked by uid 89); 4 Feb 2016 18:24:04 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,SPF_PASS autolearn=ham version=3.3.2 spammy=compose, relocating, reproducible, states X-HELO: usplmg21.ericsson.net Received: from usplmg21.ericsson.net (HELO usplmg21.ericsson.net) (198.24.6.65) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA encrypted) ESMTPS; Thu, 04 Feb 2016 18:24:01 +0000 Received: from EUSAAHC003.ericsson.se (Unknown_Domain [147.117.188.81]) by usplmg21.ericsson.net (Symantec Mail Security) with SMTP id 2E.DF.32102.A2793B65; Thu, 4 Feb 2016 19:23:38 +0100 (CET) Received: from [142.133.110.95] (147.117.188.8) by smtp-am.internal.ericsson.com (147.117.188.83) with Microsoft SMTP Server id 14.3.248.2; Thu, 4 Feb 2016 13:23:58 -0500 Subject: Re: Move threads out of jumppad without single step To: Yao Qi References: <86zixzvhj1.fsf@gmail.com> <565C6043.4040106@redhat.com> <864mg2v1s5.fsf@gmail.com> <56A8F4AE.5040305@ericsson.com> <56ABCEFF.4090506@ericsson.com> <86si18o1jh.fsf@gmail.com> CC: Pedro Alves , , From: Antoine Tremblay Message-ID: <56B3973D.9070304@ericsson.com> Date: Thu, 04 Feb 2016 18:24:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <86si18o1jh.fsf@gmail.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2016-02/txt/msg00128.txt.bz2 On 02/04/2016 11:58 AM, Yao Qi wrote: > 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. > Indeed, in fact I just tried on x86 on master and I got the same problem ending with: <<<< exiting linux_wait_1 ../../../gdb/gdbserver/linux-low.c:1922: A problem internal to GDBserver has been detected. unsuspend LWP 24815, suspended=-1 So maybe we should have seen this before ? Or my test setup is messing up the normal flow. At least it makes it easier to reproduce, you can run the same thing on x86 with master and get the same situation (See my previous mail on the exact steps). If I understand what you mean by details as a proper problem description. It's hard to provide all the details in a coherent way for me at this time since I'm not sure I understand the problem correctly, mainly due to my lack of experience with the control flow and all the states that compose this flow. That's why I asked here, see if you or Pedro could shed some light based on a reproducible program and logs. If it's non-trivial for you guys also I'll take more time to dig. > 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. That's fine with me. > 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 had not tested that at all thanks for working on it. If there's anything I can do to help please let me know. > 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. > Thanks for letting me know that's always appreciated. On my end my priority is to get the normal tracepoints in first, still a few patches waiting for review there. In the meantime even if the basic fast tracepoint patch set is ready we still need to work on the JIT condition evaluation and relocating PC relative instructions which should take some time. Regards, Antoine