From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 95332 invoked by alias); 29 Jun 2016 19:15:51 -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 94848 invoked by uid 89); 29 Jun 2016 19:15:51 -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=201602, 2016-02, traced, HX-Envelope-From:sk:antoine X-HELO: usplmg20.ericsson.net Received: from usplmg20.ericsson.net (HELO usplmg20.ericsson.net) (198.24.6.45) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA encrypted) ESMTPS; Wed, 29 Jun 2016 19:15:40 +0000 Received: from EUSAAHC008.ericsson.se (Unknown_Domain [147.117.188.96]) by usplmg20.ericsson.net (Symantec Mail Security) with SMTP id B9.A6.09012.F0414775; Wed, 29 Jun 2016 20:31:43 +0200 (CEST) Received: from elxa4wqvvz1 (147.117.188.8) by smtps-am.internal.ericsson.com (147.117.188.96) with Microsoft SMTP Server (TLS) id 14.3.294.0; Wed, 29 Jun 2016 15:15:37 -0400 References: <1465476975-25062-1-git-send-email-antoine.tremblay@ericsson.com> <0d896cd9-f857-db41-fdb1-2ebde0eeeb01@redhat.com> User-agent: mu4e 0.9.17; emacs 24.4.1 From: Antoine Tremblay To: Pedro Alves CC: Antoine Tremblay , Subject: Re: [PATCH v2 00/17] Fast tracepoint support for ARMv7 In-Reply-To: <0d896cd9-f857-db41-fdb1-2ebde0eeeb01@redhat.com> Date: Wed, 29 Jun 2016 19:15:00 -0000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain X-IsSubscribed: yes X-SW-Source: 2016-06/txt/msg00526.txt.bz2 Pedro Alves writes: > On 06/29/2016 02:55 PM, Antoine Tremblay wrote: > >>> There is a possible issue while stepping out of the jump pad as discussed >>> here: https://sourceware.org/ml/gdb-patches/2016-01/msg00673.html >>> >>> But this issue is present in x86 with hardware single stepping too. So I >>> don't think it's related to this series and can be addressed separately. >>> I'm still mentioning it as it may be relevant while testing software >>> single stepping out of the jump pad. > > I follows that url now, and I didn't see where it's mentioned > that the issue is present with x86 as well? It talks about > single-step breakpoints, which x86 doesn't use? > Yes the threading is a bit strange, the proper url for x86 reference is : https://sourceware.org/ml/gdb-patches/2016-02/msg00128.html > IIRC, Yao's software single-step series fixes several bugs that > manifest in suspend count assertions failing. Are you working on top > of that? > I was testing on x86... >> >> About this possible known issue, after more investigation it turns out >> this is because my test to try to test moving out of the jump pad is >> flawed. So there's no reason to believe that the software single step to >> move out of the jump pad has a problem based on that. >> >> The fact that I would stop a thread with a breakpoint inside the >> jumppad is problematic since even if I removed the breakpoint to >> simulate that gdb happened to stop there while the process was >> interrupted gdb still assumes with last_resume_kind that the user wants >> this thread stopped and thus it fails go through the proper code >> paths. > > If you put a breakpoint inside gdb_collect or one of its callees, > then gdbserver is supposed to not try to move threads out of the > jump pads. This is to allow debugging the fast tracepoint machinery > itself. > Yes indeed that's what I discovered.. thus my flawed test. >> >> I tried testing the moving out of jump pad logic by running a while loop >> with only one fast tracepoint collecting there and then interrupting it >> at random but surprisingly this has some problems. >> >> It seems the trace stops on it's own even with buffer size unlimited on >> x86, I'm not sure if the trace buffer can actually be unlimited so I >> tested also with circular-buffers on and this that I just can't >> interrupt the process... >> >> Would anyone have an idea on a way to test the move out of the jump pad >> logic ? Pedro maybe ? Did you have a way to test it when you wrote that >> code ? > > I think I remember doing basically what you did -- run a tight > loop that is constantly collecting a fast tracepoint, and then send > the inferior a signal. Then I'd do "bt" and look for a "gdb_collect" > frame. If one was shown, there was a bug. I remember trying and > observing all the nasty situations described on top > of linux_stabilize_threads, but I don't remember ever converting them > to proper testcases... :-/ > OK, I guess I have to find a way to interrupt it, in my case using a circular buffer, trying c& and interrupt as no effect or C-c with continue... I'll try a less tight loop and check that's it's in the traced code but not in the usleep... In the meantime it made me test arm fast tracepoints with a thight loop like that and it crashes the inferiror when the agent buffer is full :( I'll fix that 1st.. Thanks, Antoine