From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24293 invoked by alias); 4 Dec 2012 12:47:22 -0000 Received: (qmail 24239 invoked by uid 22791); 4 Dec 2012 12:47:19 -0000 X-SWARE-Spam-Status: No, hits=-7.6 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_SPAMHAUS_DROP,KHOP_THREADED,RCVD_IN_DNSWL_HI,RCVD_IN_HOSTKARMA_W,RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 04 Dec 2012 12:47:12 +0000 Received: from orsmga002.jf.intel.com ([10.7.209.21]) by orsmga101.jf.intel.com with ESMTP; 04 Dec 2012 04:47:11 -0800 X-ExtLoop1: 1 Received: from irsmsx102.ger.corp.intel.com ([163.33.3.155]) by orsmga002.jf.intel.com with ESMTP; 04 Dec 2012 04:47:09 -0800 Received: from irsmsx152.ger.corp.intel.com (163.33.192.66) by IRSMSX102.ger.corp.intel.com (163.33.3.155) with Microsoft SMTP Server (TLS) id 14.1.355.2; Tue, 4 Dec 2012 12:47:08 +0000 Received: from irsmsx102.ger.corp.intel.com ([169.254.2.95]) by IRSMSX152.ger.corp.intel.com ([169.254.6.36]) with mapi id 14.01.0355.002; Tue, 4 Dec 2012 12:47:08 +0000 From: "Metzger, Markus T" To: Pedro Alves CC: "gdb-patches@sourceware.org" , "markus.t.metzger@gmail.com" , "jan.kratochvil@redhat.com" , "tromey@redhat.com" , "kettenis@gnu.org" Subject: RE: [patch v4 08/13] remote, btrace: add branch trace remote ops Date: Tue, 04 Dec 2012 12:47:00 -0000 Message-ID: References: <1354013351-14791-1-git-send-email-markus.t.metzger@intel.com> <1354013351-14791-9-git-send-email-markus.t.metzger@intel.com> <50B664AE.1020006@redhat.com> In-Reply-To: <50B664AE.1020006@redhat.com> Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes 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 X-SW-Source: 2012-12/txt/msg00057.txt.bz2 > -----Original Message----- > From: Pedro Alves [mailto:palves@redhat.com] > Sent: Wednesday, November 28, 2012 8:23 PM Thanks for your review. [...] > > Qbtrace:on: enable branch tracing for one thread > > returns "OK" or "Enn" > > > > Qbtrace:off: disable branch tracing for one thread > > returns "OK" or "Enn" >=20 > Nit, I'd put first: In the context of your comment regarding qXfer:btrace:read, should I rather= omit the ptid here, as well, and use set_general_thread? > > Qbtrace::on enable branch tracing for one thread > > returns "OK" or "Enn" > > > > Qbtrace::off disable branch tracing for one thread > > returns "OK" or "Enn" >=20 >=20 > How does "btrace enable all" for new threads work with remote targets? > GDB isn't notified of new threads until they stop for some reason. I ran into this problem, as well. At the moment, btrace is configured after= the first stop. This is not what I would want, but all that I could get. Is this some conscious design decision? Is gdbserver supposed to handle thi= s automatic enabling? Or could we change this and have gdbserver notify gdb= about new threads? This would also address the update_therad_list problem,= where commands might work on an outdated thread list until the user says "= info threads". [...] > > +struct btrace_target_info > > +{ > > + /* The ptid of the traced thread. */ > > + ptid_t ptid; > > +}; >=20 > Hmm, why would you need to store this? To get at a struct btrace_target_= info, > you need to start from a struct thread_info, so why not just pass that > down, or pass the ptid down? This struct is supposed to contain all the information gdb needs to impleme= nt branch tracing for one thread. In the native case, it holds the perf eve= nt ring buffer and the perf event configuration. In the remote case, it hol= ds the ptid for communication with gdbserver. The perf event specific data = is stored in gdbserver. If I passed a struct thread_info, btrace related functions would work direc= tly on the thread info. I would still need some mechanism to store differen= t data for different implementations. And I also use the btrace_target_info= pointer to indicate whether btrace has been enabled for this thread. [...] Thanks, Markus. Intel GmbH Dornacher Strasse 1 85622 Feldkirchen/Muenchen, Deutschland Sitz der Gesellschaft: Feldkirchen bei Muenchen Geschaeftsfuehrer: Christian Lamprechter, Hannes Schwaderer, Douglas Lusk Registergericht: Muenchen HRB 47456 Ust.-IdNr./VAT Registration No.: DE129385895 Citibank Frankfurt a.M. (BLZ 502 109 00) 600119052