From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 122803 invoked by alias); 30 Nov 2016 09:54:42 -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 119568 invoked by uid 89); 30 Nov 2016 09:54:39 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-4.6 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 spammy=BTS, D*ericsson.com, Tel, tel X-HELO: mga03.intel.com Received: from mga03.intel.com (HELO mga03.intel.com) (134.134.136.65) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 30 Nov 2016 09:54:29 +0000 Received: from orsmga003.jf.intel.com ([10.7.209.27]) by orsmga103.jf.intel.com with ESMTP; 30 Nov 2016 01:54:23 -0800 X-ExtLoop1: 1 Received: from irsmsx108.ger.corp.intel.com ([163.33.3.3]) by orsmga003.jf.intel.com with ESMTP; 30 Nov 2016 01:54:22 -0800 Received: from irsmsx104.ger.corp.intel.com ([169.254.5.52]) by IRSMSX108.ger.corp.intel.com ([169.254.11.145]) with mapi id 14.03.0248.002; Wed, 30 Nov 2016 09:54:21 +0000 From: "Metzger, Markus T" To: Simon Marchi , "gdb-patches@sourceware.org" Subject: RE: [PATCH] Prevent turning record on while threads are running (PR 20869) Date: Wed, 30 Nov 2016 09:54:00 -0000 Message-ID: References: <20161129150758.29912-1-simon.marchi@ericsson.com> In-Reply-To: <20161129150758.29912-1-simon.marchi@ericsson.com> Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2016-11/txt/msg00967.txt.bz2 > -----Original Message----- > From: Simon Marchi [mailto:simon.marchi@ericsson.com] > Sent: Tuesday, November 29, 2016 4:08 PM > To: gdb-patches@sourceware.org > Cc: Metzger, Markus T ; Simon Marchi > > Subject: [PATCH] Prevent turning record on while threads are running (PR = 20869) Hi Simon, Thanks for looking into this. > I also wanted to know whether it was supported to start btrace bts/pt > recording with threads running. When I try it with btrace bts, it works > halfway. "record btrace bts" gives me the error: >=20 > Couldn't get registers: No such process. >=20 > If I do the command again, gdb doesn't complain and then I'm able to > interrupt the target and use reverse-next. However, since the > initialization function was interrupted halfway, I am not sure that > everything is setup correctly. If we want to allow it, we would first > need to look into this issue. The issue with record-btrace is that tracing can be enabled on the target a= lso for running threads. When we try to insert the first record for the current PC= so the trace starts at the location from where we disabled tracing, regcache_read_= pc throws the above error. Since record_btrace_open has not installed a clean= up to disable tracing again for this thread, we leave it enabled. (gdb) rec bts [record-btrace] open [btrace] enable thread 1 (Thread 0x7ffff7fcd740 (LWP 110345)) [btrace] compute ftrace [btrace] enable thread 2 (Thread 0x7ffff77fd700 (LWP 110346)) [btrace] disable thread 1 (Thread 0x7ffff7fcd740 (LWP 110345)) [btrace] clear thread 1 (Thread 0x7ffff7fcd740 (LWP 110345)) Couldn't get registers: No such process. The next time we try to enable tracing, that running thread is already trac= ed so we skip it. If we have more than two threads running, we disable tracing a= gain on this thread when we fail on the next running thread. But we always leav= e the highest-number running thread traced. (gdb)=20 [record-btrace] open [btrace] enable thread 1 (Thread 0x7ffff7fcd740 (LWP 110345)) [btrace] compute ftrace [btrace] enable thread 4 (Thread 0x7ffff67fb700 (LWP 110348)) [btrace] disable thread 3 (Thread 0x7ffff6ffc700 (LWP 110347)) [btrace] clear thread 3 (Thread 0x7ffff6ffc700 (LWP 110347)) [btrace] disable thread 2 (Thread 0x7ffff77fd700 (LWP 110346)) [btrace] clear thread 2 (Thread 0x7ffff77fd700 (LWP 110346)) [btrace] disable thread 1 (Thread 0x7ffff7fcd740 (LWP 110345)) [btrace] clear thread 1 (Thread 0x7ffff7fcd740 (LWP 110345)) Couldn't get registers: No such process. Eventually, all running threads are already traced and we succeed to enable= tracing. The trace for running threads will start from their next branch target inst= ead of from their current position (for BTS). This shouldn't matter unless the thread was ac= tually waiting and not executing any code when we started tracing. We should be able to a= llow it like this: diff --git a/gdb/btrace.c b/gdb/btrace.c index 39d537c..b005627 100644 --- a/gdb/btrace.c +++ b/gdb/btrace.c @@ -1474,8 +1474,28 @@ btrace_enable (struct thread_info *tp, const struct = btrace_config *conf) =20 /* Add an entry for the current PC so we start tracing from where we enabled it. */ - if (tp->btrace.target !=3D NULL) - btrace_add_pc (tp); + TRY + { + if (tp->btrace.target !=3D NULL) + btrace_add_pc (tp); + } + CATCH (error, RETURN_MASK_ERROR) + { + /* We may fail to add the initial entry, for example if TP is curren= tly + running. + + For BTRACE_FORMAT_PT this doesn't matter. + + For BTRACE_FORMAT_BTS we won't be able to stitch the initial trace + chunk to this initial entry so tracing will start at the next bran= ch + target instead of at the current PC. Since TP is currently runnin= g, + this shouldn't make a difference. + + If TP were waiting most of the time and made only a little bit of + progress before it was stopped, we'd lose the instructions until t= he + first branch. */ + } + END_CATCH } =20 /* See btrace.h. */ Do you want to extend your patch to allow tracing to be enabled for btrace = or would you rather have me fix this on top of your patch? Thanks, Markus. Intel Deutschland GmbH Registered Address: Am Campeon 10-12, 85579 Neubiberg, Germany Tel: +49 89 99 8853-0, www.intel.de Managing Directors: Christin Eisenschmid, Christian Lamprechter Chairperson of the Supervisory Board: Nicole Lau Registered Office: Munich Commercial Register: Amtsgericht Muenchen HRB 186928