From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 555 invoked by alias); 22 Dec 2012 13:08:29 -0000 Received: (qmail 32725 invoked by uid 22791); 22 Dec 2012 13:08:29 -0000 X-SWARE-Spam-Status: No, hits=-6.2 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,RCVD_IN_DNSWL_HI,SPF_HELO_PASS,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sat, 22 Dec 2012 13:08:21 +0000 Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id qBMD8IFQ016039 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 22 Dec 2012 08:08:18 -0500 Received: from host2.jankratochvil.net (ovpn-116-39.ams2.redhat.com [10.36.116.39]) by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id qBMD8Dhk013266 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Sat, 22 Dec 2012 08:08:16 -0500 Date: Sat, 22 Dec 2012 13:08:00 -0000 From: Jan Kratochvil To: "Metzger, Markus T" Cc: "palves@redhat.com" , "tromey@redhat.com" , "kettenis@gnu.org" , "gdb-patches@sourceware.org" , "markus.t.metzger@gmail.com" Subject: Re: [patch v6 00/12] branch tracing support for Atom Message-ID: <20121222130812.GA6195@host2.jankratochvil.net> References: <1355760101-26237-1-git-send-email-markus.t.metzger@intel.com> <20121218091953.GF8054@host2.jankratochvil.net> <20121218135437.GA16636@host2.jankratochvil.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) 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/msg00779.txt.bz2 On Wed, 19 Dec 2012 10:59:37 +0100, Metzger, Markus T wrote: > At the same time, I wanted some always-on functionality so I didn't have to > repeatedly enable tracing. I therefore added two different versions: "btrace > enable [all, ]" and "btrace enable auto". I miss a bit (1) some resulting message saying "New threads will get branch tracing turned on automatically." and message like "Thread 2 already has branch tracing turned on." + "Thread 3 branch tracing has been turned on." or something like that. And (2) "info btrace" - or with the new move under record - "info record" where it displays for each thread whether the tracing is on or off and whether new threads get traced or not. Maybe it could be also added to "info threads", if you want to / there is no objection to it. With existing "record" one knows unfortunately very well whether the tracing is turned on (=it is very slow). > Record/replay uses another target on top of the current. It needs to be > enabled for a running process each time I do not think it is appropriate for "record". As it is very slow one wants to record on the interesting last spot of the execution. But in principle I think the feature should apply for all (both) record backends - both the current and the btrace one. > and it does not allow selective enabling/disabling per thread. This may be a missing feature for the "record" functionality, it would be also good to share it with btrace, at least for the CLI interface design for now. > If I just followed the "target record" command, I would lose the selective > enabling as well as the automatic enabling Pushing of the new target could be hooked to to_post_startup_inferior and to_post_attach, I hope that's enough. > - and I would risk that not all threads will be traced when running out of > resources. I do not understand here which resources may be unavailable and what GDB can about it. Thanks, Jan