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

["Metzger, Markus T" <markus.t.metzger@intel.com>]

> -----Original Message-----
> From: Jan Kratochvil [mailto:jan.kratochvil@redhat.com]
> Sent: Thursday, March 28, 2013 7:28 AM


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

Thanks, I'll try that.  Although, in the end, it's really the same as if we made
other frames prologue cache visible.


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

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?

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