This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [draft patch] <unavailable> unwinder for btrace [Re: [rfc 3/5] record: make it build again]
- From: Jan Kratochvil <jan dot kratochvil at redhat dot com>
- To: Markus Metzger <markus dot t dot metzger at googlemail dot com>
- Cc: gdb-patches at sourceware dot org, "Metzger, Markus T" <markus dot t dot metzger at intel dot com>
- Date: Thu, 28 Mar 2013 07:27:47 +0100
- Subject: Re: [draft patch] <unavailable> unwinder for btrace [Re: [rfc 3/5] record: make it build again]
- References: <1360337423-27095-1-git-send-email-markus dot t dot metzger at intel dot com> <1360337423-27095-4-git-send-email-markus dot t dot metzger at intel dot com> <20130210221059 dot GC4819 at host2 dot jankratochvil dot net> <A78C989F6D9628469189715575E55B2307B78A04 at IRSMSX102 dot ger dot corp dot intel dot com> <20130211141451 dot GA8962 at host2 dot jankratochvil dot net> <20130211171319 dot GA17524 at host2 dot jankratochvil dot net> <A78C989F6D9628469189715575E55B2307BA9030 at IRSMSX102 dot ger dot corp dot intel dot com> <9B969C1D-95E8-4AD5-BEF0-E269FF8771DF at gmail dot com>
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