From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 95932 invoked by alias); 29 Jun 2016 16:59:22 -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 95917 invoked by uid 89); 29 Jun 2016 16:59:22 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.2 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=constantly, surprisingly, Hx-languages-length:2707 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Wed, 29 Jun 2016 16:59:10 +0000 Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 837A83F725; Wed, 29 Jun 2016 16:59:08 +0000 (UTC) Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u5TGx7cU022700; Wed, 29 Jun 2016 12:59:07 -0400 Subject: Re: [PATCH v2 00/17] Fast tracepoint support for ARMv7 To: Antoine Tremblay , gdb-patches@sourceware.org References: <1465476975-25062-1-git-send-email-antoine.tremblay@ericsson.com> From: Pedro Alves Message-ID: <0d896cd9-f857-db41-fdb1-2ebde0eeeb01@redhat.com> Date: Wed, 29 Jun 2016 16:59:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SW-Source: 2016-06/txt/msg00524.txt.bz2 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? IIRC, Yao's software single-step series fixes several bugs that manifest in suspend count assertions failing. Are you working on top of that? > > 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. > > 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... :-/ Thanks, Pedro Alves