From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 83720 invoked by alias); 20 Nov 2015 13:59:07 -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 83698 invoked by uid 89); 20 Nov 2015 13:59:05 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.7 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mga14.intel.com Received: from mga14.intel.com (HELO mga14.intel.com) (192.55.52.115) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 20 Nov 2015 13:59:04 +0000 Received: from orsmga001.jf.intel.com ([10.7.209.18]) by fmsmga103.fm.intel.com with ESMTP; 20 Nov 2015 05:59:04 -0800 X-ExtLoop1: 1 Received: from irsmsx107.ger.corp.intel.com ([163.33.3.99]) by orsmga001.jf.intel.com with ESMTP; 20 Nov 2015 05:59:02 -0800 Received: from irsmsx104.ger.corp.intel.com ([169.254.5.138]) by IRSMSX107.ger.corp.intel.com ([169.254.10.132]) with mapi id 14.03.0248.002; Fri, 20 Nov 2015 13:59:01 +0000 From: "Metzger, Markus T" To: Pedro Alves CC: "gdb-patches@sourceware.org" Subject: RE: [PATCH] btrace: diagnose "record btrace pt" without libipt Date: Fri, 20 Nov 2015 13:59:00 -0000 Message-ID: References: <1448011026-4192-1-git-send-email-markus.t.metzger@intel.com> <564F0591.3020006@redhat.com> <564F1C3D.1040709@redhat.com> In-Reply-To: <564F1C3D.1040709@redhat.com> Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2015-11/txt/msg00424.txt.bz2 > -----Original Message----- > From: Pedro Alves [mailto:palves@redhat.com] > Sent: Friday, November 20, 2015 2:12 PM > To: Metzger, Markus T > Cc: gdb-patches@sourceware.org > Subject: Re: [PATCH] btrace: diagnose "record btrace pt" without libipt >=20 > On 11/20/2015 12:11 PM, Metzger, Markus T wrote: >=20 > > The record target is popped off the target stack on disconnect. This > disables > > branch tracing. The below log is for BTS but the logic is the same for= PT. > > Sending packet: $Qbtrace:off#37...Packet received: OK >=20 > > > > After reconnecting, you need to enable btrace again. >=20 > I see. But then it sounds like we'll have the problem if the connection > drops unexpectedly -- gdb won't be able to tell the server to > disable Qbtrace. I guess the easiest way to emulate is kill gdb: >=20 > #1 - enable btrace pt > #2 - connection is terminated unexpectedly / kill gdb > #3 - reconnect to gdbserver >=20 > a) Does the new gdb get out of sync and confused? Yes. GDB doesn't recognize that the remote agent is already tracing. This also prevents enabling branch tracing after reconnect. (gdb) info rec No record target is currently active. (gdb) rec b [record-btrace] open [record-btrace] open [btrace] enable thread 1 (Thread 141484) Sending packet: $Qbtrace-conf:bts:size=3D0x10000#e3...Packet received: = OK Sending packet: $Qbtrace:bts#45...Packet received: E.Btrace already ena= bled. Could not enable branch tracing for Thread 141484: Btrace already enabl= ed. (gdb) info rec No record target is currently active. (gdb) Thanks for pointing this out. Let's try to fix it... Handling the "E.Btrace already enabled" error in remote.c shouldn't be too = hard. This would at least allow another "record btrace" after reconnect - and it = should keep the trace logs. This takes the same code path as a new enable so the = check in this patch should suffice. A non-PT enabled GDB would try to fall back to BTS, though, so we could eit= her implicitly disable PT in the target to allow it or give an error, which aga= in leaves branch tracing unusable in this GDB session. But it would keep the trace l= ogs if the user accidentally chose the wrong GDB for reconnecting. It would be nice if GDB could detect that record btrace is already enabled = and push the record-btrace target automatically. I guess this requires some indicat= ion about the record status from gdbserver. Is there some other target that does thi= s automatic push on (re-)connect that I could use as reference? This still leaves the question how GDB should behave if it doesn't support = the tracing format that's already enabled in the GDBserver it just connected to. Regards, 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