From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12123 invoked by alias); 27 Mar 2013 15:23:17 -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 12104 invoked by uid 89); 27 Mar 2013 15:23:09 -0000 X-Spam-SWARE-Status: No, score=-8.5 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_THREADED,RCVD_IN_DNSWL_HI,RCVD_IN_HOSTKARMA_W,RP_MATCHES_RCVD autolearn=ham version=3.3.1 Received: from mga14.intel.com (HELO mga14.intel.com) (143.182.124.37) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Wed, 27 Mar 2013 15:23:07 +0000 Received: from azsmga001.ch.intel.com ([10.2.17.19]) by azsmga102.ch.intel.com with ESMTP; 27 Mar 2013 08:23:05 -0700 X-ExtLoop1: 1 Received: from irsmsx101.ger.corp.intel.com ([163.33.3.153]) by azsmga001.ch.intel.com with ESMTP; 27 Mar 2013 08:23:04 -0700 Received: from irsmsx102.ger.corp.intel.com ([169.254.2.244]) by IRSMSX101.ger.corp.intel.com ([169.254.1.99]) with mapi id 14.01.0355.002; Wed, 27 Mar 2013 15:22:08 +0000 From: "Metzger, Markus T" To: Jan Kratochvil CC: "gdb-patches@sourceware.org" , "markus.t.metzger@gmail.com" Subject: RE: [draft patch] unwinder for btrace [Re: [rfc 3/5] record: make it build again] Date: Wed, 27 Mar 2013 18:09:00 -0000 Message-ID: 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> In-Reply-To: <20130211171319.GA17524@host2.jankratochvil.net> Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-SW-Source: 2013-03/txt/msg01022.txt.bz2 > -----Original Message----- > From: Jan Kratochvil [mailto:jan.kratochvil@redhat.com] > Sent: Monday, February 11, 2013 6:13 PM [...] > 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. 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? If not, would you please point me to some code that I would need to touch to replace the sentinel frame? Would I maybe provide another target method to allow targets to overwrite the sentinel frame? 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? 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. 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