From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18084 invoked by alias); 27 Nov 2012 16:28:10 -0000 Received: (qmail 18053 invoked by uid 22791); 27 Nov 2012 16:28:08 -0000 X-SWARE-Spam-Status: No, hits=-6.5 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,RCVD_IN_DNSWL_HI,RCVD_IN_HOSTKARMA_W,RP_MATCHES_RCVD,SPF_HELO_PASS 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; Tue, 27 Nov 2012 16:27:57 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id qARGRl1h004368 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 27 Nov 2012 11:27:47 -0500 Received: from host2.jankratochvil.net (ovpn-116-39.ams2.redhat.com [10.36.116.39]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id qARGRfHH018898 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 27 Nov 2012 11:27:44 -0500 Date: Tue, 27 Nov 2012 16:28:00 -0000 From: Jan Kratochvil To: "Metzger, Markus T" Cc: "gdb-patches@sourceware.org" , "markus.t.metzger@gmail.com" , "palves@redhat.com" , "tromey@redhat.com" , "kettenis@gnu.org" Subject: Re: [patch v4 00/13] branch tracing support for Atom Message-ID: <20121127162740.GA4512@host2.jankratochvil.net> References: <1354013351-14791-1-git-send-email-markus.t.metzger@intel.com> <20121127131055.GB22431@host2.jankratochvil.net> <20121127143235.GA31270@host2.jankratochvil.net> <20121127153603.GA1899@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-11/txt/msg00753.txt.bz2 On Tue, 27 Nov 2012 17:16:30 +0100, Metzger, Markus T wrote: > Looks like it wouldn't be that difficult, after all. The assumption that > a ret returns to the last call we've seen might be a bit optimistic, though. > And we wouldn't be able to handle those cases where the call is not included > in the trace. The back trace would thus be rather short. In which case the call is not present in the btrace recoding? We also have the recording initial PC and we can also record the backtrace at that initial PC. There is wrong assumption if we record code from some later dlclose-d library but that normally should not happen. > Btrace is very helpful for debugging stack corruptions. It can show you > where you came from even if gdb is not able to unwind properly. True, I forgot about this common one. Thanks, Jan