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: "Metzger, Markus T" <markus dot t dot metzger at intel dot com>
- Cc: Markus Metzger <markus dot t dot metzger at googlemail dot com>, "gdb-patches at sourceware dot org" <gdb-patches at sourceware dot org>
- Date: Thu, 28 Mar 2013 10:12:04 +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> <20130328062747 dot GA27157 at host2 dot jankratochvil dot net> <A78C989F6D9628469189715575E55B2307BA984B at IRSMSX102 dot ger dot corp dot intel dot com>
On Thu, 28 Mar 2013 08:44:12 +0100, Metzger, Markus T wrote:
> Thanks, I'll try that. Although, in the end, it's really the same as if we made
> other frames prologue cache visible.
Yes. You can make a separate patch to make it visible but one htab_t may be
easier. With public cache pointer someone could misues it inappropriately
etc.
> > > > 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.
>
> The data structure should only change when there is new trace, which requires
> the target to continue. "info record" should, like any other record-btrace command,
> fetch the new trace once and then operate on the cached trace data.
In non-stop mode I belive there will be new btrace info on each "info record"
command, won't be? I have not tried it but it seems so to me.
> Is there a guarantee that frame_info and frame_id objects are destroyed
> when the target resumes? Or could I trigger their destruction from within
> btrace_clear?
"trigger frame_info and frame_id destruction" == reinit_frame_cache().
Accessing frame_info after reinit_frame_cache() is always a crash.
Accessing frame_id after reinit_frame_cache() is safe but one needs to be
prepared frame_find_by_id may return NULL if it is no longer available.
When you introduce new reinit_frame_cache() call one just needs to be careful
no caller holds that time a frame_info * pointer in a local variable.
It would be a bug in such caller to call some non-trivial caller while holding
frame_info * but there were many such bugs in GDB.
I would not rely on any reinit_frame_cache() calls, calling
reinit_frame_cache() more times is zero-cost, I think you should call
reinit_frame_cache() from btrace_clear as you ask above.
Thanks,
Jan