Re: [draft patch] <unavailable> unwinder for btrace [Re: [rfc 3/5] record: make it build again]

[Markus Metzger <markus.t.metzger@googlemail.com>]

On Mar 27, 2013, at 16:22 , "Metzger, Markus T" <markus.t.metzger@intel.com> wrote:

>> -----Original Message-----
>> From: Jan Kratochvil [mailto:jan.kratochvil@redhat.com]
>> Sent: Monday, February 11, 2013 6:13 PM
> 
> [...]
> 
>> gdb/
>> 2013-02-11  Jan Kratochvil  <jan.kratochvil@redhat.com>
>> 
>> 	New record unwinder reporting <unavailable>.
>> 	* 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?

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.
> 
> 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.

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: <gdb-patches-return-99987-listarch-gdb-patches=sources.redhat.com@sourceware.org>
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: <gdb-patches.sourceware.org>
List-Subscribe: <mailto:gdb-patches-subscribe@sourceware.org>
List-Archive: <http://sourceware.org/ml/gdb-patches/>
List-Post: <mailto:gdb-patches@sourceware.org>
List-Help: <mailto:gdb-patches-help@sourceware.org>, <http://sourceware.org/ml/#faqs>
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%6 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\x128 verify=NO);	Thu, 28 Mar 2013 02:27:52 -0400
Date: Thu, 28 Mar 2013 14:21:00 -0000
From: Jan Kratochvil <jan.kratochvil@redhat.com>
To: Markus Metzger <markus.t.metzger@googlemail.com>
Cc: gdb-patches@sourceware.org,        "Metzger, Markus T" <markus.t.metzger@intel.com>
Subject: Re: [draft patch] <unavailable> 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> <A78C989F6D9628469189715575E55B2307B78A04@IRSMSX102.ger.corp.intel.com> <20130211141451.GA8962@host2.jankratochvil.net> <20130211171319.GA17524@host2.jankratochvil.net> <A78C989F6D9628469189715575E55B2307BA9030@IRSMSX102.ger.corp.intel.com> <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" <markus.t.metzger@intel.com> 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