From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9948 invoked by alias); 28 Mar 2013 06:09:36 -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 9904 invoked by uid 89); 28 Mar 2013 06:09:22 -0000 X-Spam-SWARE-Status: No, score=-5.4 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,KHOP_RCVD_TRUST,KHOP_THREADED,RCVD_IN_DNSWL_LOW,RCVD_IN_HOSTKARMA_YE autolearn=ham version=3.3.1 Received: from mail-ea0-f178.google.com (HELO mail-ea0-f178.google.com) (209.85.215.178) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Thu, 28 Mar 2013 06:09:19 +0000 Received: by mail-ea0-f178.google.com with SMTP id o10so616002eaj.37 for ; Wed, 27 Mar 2013 23:09:17 -0700 (PDT) X-Received: by 10.14.202.71 with SMTP id c47mr62887020eeo.39.1364450957137; Wed, 27 Mar 2013 23:09:17 -0700 (PDT) Received: from [192.168.0.10] (HSI-KBW-078-043-072-214.hsi4.kabel-badenwuerttemberg.de. [78.43.72.214]) by mx.google.com with ESMTPS id q5sm35495219eeo.17.2013.03.27.23.09.15 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 27 Mar 2013 23:09:16 -0700 (PDT) Subject: Re: [draft patch] unwinder for btrace [Re: [rfc 3/5] record: make it build again] Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Content-Type: text/plain; charset=us-ascii From: Markus Metzger In-Reply-To: Date: Thu, 28 Mar 2013 12:38:00 -0000 Cc: gdb-patches@sourceware.org, "Metzger, Markus T" Content-Transfer-Encoding: quoted-printable Message-Id: <9B969C1D-95E8-4AD5-BEF0-E269FF8771DF@gmail.com> References: <1360337423-27095-1-git-send-email-markus.t.metzger@intel.com> <1360337423-27095-4-git-send-email-markus.t.metzger@intel.com> <20130210221059.GC4819@host2.jankratochvil.net> <20130211141451.GA8962@host2.jankratochvil.net> <20130211171319.GA17524@host2.jankratochvil.net> To: Jan Kratochvil X-SW-Source: 2013-03/txt/msg01051.txt.bz2 On Mar 27, 2013, at 16:22 , "Metzger, Markus T" wrote: >> -----Original Message----- >> From: Jan Kratochvil [mailto:jan.kratochvil@redhat.com] >> Sent: Monday, February 11, 2013 6:13 PM >=20 > [...] >=20 >> gdb/ >> 2013-02-11 Jan Kratochvil >>=20 >> New record unwinder reporting . >> * dwarf2-frame.c (dwarf2_frame_cfa): Move UNWIND_UNAVAILABLE check >> earlier. >> * frame-unwind.c: Include target.h. >> (frame_unwind_try_unwinder): New function with code from ... >> (frame_unwind_find_by_frame): ... here. New variable >> unwinder_from_target, call also target_get_unwinder and >> frame_unwind_try_unwinder for it. >> * frame.c (get_frame_unwind_stop_reason): Unconditionally call >> get_prev_frame_1. >> * record.c: Include frame-unwind.h. >> (record_frame_unwind_stop_reason, record_frame_this_id) >> (record_frame_prev_register, record_frame_sniffer, record_frame_unwind): >> New. >> (init_record_ops, init_record_core_ops): Install it. >> * target.c (target_get_unwinder): New. >> * target.h (struct target_ops): New field to_get_unwinder. >> (target_get_unwinder): New declaration. >=20 > I've been experimenting with this a bit. It looks like there will always= be > a sentinel frame at the very bottom that is reading the registers directly > from the inferior. I can only hook in at the second frame. >=20 > In order to fake the back trace for btrace replay, I would also need to > replace the sentinel frame, since otherwise, the first frame will always > point to the current location. >=20 > Am I doing something wrong? Yes, I am. I need to also provide the target registers. Then the sentinel frame should do exactly what I want. > On a related but different topic, I added a btrace frame type and > prologue cache. The cache holds a pointer to some btrace data > structure that is used to compute the fake back trace. In order to > unwind a btrace frame, I would need to access the next frame's > location in this btrace data structure. >=20 > The easiest would be to check for the next frame's type and then > access it's cache - which doesn't work since struct frame_info is > opaque. I ended up encoding the pointer into the special_addr > of a btrace frame's frame_id - which is somewhat ugly. Any better > idea? >=20 > Also what's the lifetime of a frame_info and frame_id object? > When the branch trace is cleared, any pointers to it will become > stale. Those remain open. regards, markus. >From gdb-patches-return-99987-listarch-gdb-patches=sources.redhat.com@sourceware.org Thu Mar 28 06:28:08 2013 Return-Path: Delivered-To: listarch-gdb-patches@sources.redhat.com Received: (qmail 15197 invoked by alias); 28 Mar 2013 06:28: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 Delivered-To: mailing list gdb-patches@sourceware.org Received: (qmail 15177 invoked by uid 89); 28 Mar 2013 06:28:00 -0000 X-Spam-SWARE-Status: No, score=-7.0 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,RCVD_IN_DNSWL_HI,RCVD_IN_HOSTKARMA_W,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.1 Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Thu, 28 Mar 2013 06:27:58 +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 r2S6RtEm025729 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 28 Mar 2013 02:27:55 -0400 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 r2S6Rm5m018800 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Thu, 28 Mar 2013 02:27:52 -0400 Date: Thu, 28 Mar 2013 14:21:00 -0000 From: Jan Kratochvil To: Markus Metzger Cc: gdb-patches@sourceware.org, "Metzger, Markus T" Subject: Re: [draft patch] unwinder for btrace [Re: [rfc 3/5] record: make it build again] Message-ID: <20130328062747.GA27157@host2.jankratochvil.net> References: <1360337423-27095-1-git-send-email-markus.t.metzger@intel.com> <1360337423-27095-4-git-send-email-markus.t.metzger@intel.com> <20130210221059.GC4819@host2.jankratochvil.net> <20130211141451.GA8962@host2.jankratochvil.net> <20130211171319.GA17524@host2.jankratochvil.net> <9B969C1D-95E8-4AD5-BEF0-E269FF8771DF@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9B969C1D-95E8-4AD5-BEF0-E269FF8771DF@gmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-IsSubscribed: yes X-SW-Source: 2013-03/txt/msg01052.txt.bz2 Content-length: 2091 On Thu, 28 Mar 2013 07:09:23 +0100, Markus Metzger wrote: > On Mar 27, 2013, at 16:22 , "Metzger, Markus T" wrote: > > I've been experimenting with this a bit. It looks like there will always be > > a sentinel frame at the very bottom that is reading the registers directly > > from the inferior. I can only hook in at the second frame. > > > > In order to fake the back trace for btrace replay, I would also need to > > replace the sentinel frame, since otherwise, the first frame will always > > point to the current location. > > > > Am I doing something wrong? > > Yes, I am. I need to also provide the target registers. Then the > sentinel frame should do exactly what I want. It looks right to me. > > On a related but different topic, I added a btrace frame type and > > prologue cache. The cache holds a pointer to some btrace data > > structure that is used to compute the fake back trace. In order to > > unwind a btrace frame, I would need to access the next frame's > > location in this btrace data structure. > > > > The easiest would be to check for the next frame's type and then > > access it's cache - which doesn't work since struct frame_info is > > opaque. I ended up encoding the pointer into the special_addr > > of a btrace frame's frame_id - which is somewhat ugly. Any better > > idea? special_addr is really not right. dwarf2-frame-tailcall.c uses for a similar problem 'htab_t cache_htab' which is indexed by 'struct frame_info *' which you can iterate in any direction so you even do not need a new cache entry for every 'struct frame_info *'. > > Also what's the lifetime of a frame_info and frame_id object? > > When the branch trace is cleared, any pointers to it will become > > stale. There is frame_unwind->dealloc_cache, any reinit_frame_cache() call inside GDB will clear the prologue cache which is very common. I see now btrace_thread_info->btrace may change more often - such as during each "info record" command. So call reinit_frame_cache() in the cases btrace cache may get rebuilt. Thanks, Jan