[draft patch] <unavailable> unwinder for btrace [Re: [rfc 3/5] record: make it build again]
Metzger, Markus T
markus.t.metzger@intel.com
Thu Mar 28 17:37:00 GMT 2013
> -----Original Message-----
> From: gdb-patches-owner@sourceware.org [mailto:gdb-patches-owner@sourceware.org] On Behalf Of Jan Kratochvil
> Sent: Thursday, March 28, 2013 10:12 AM
> > 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.
Record_btrace_info, like any other record btrace command, calls btrace_fetch.
This queries the target for new branch trace. If there is no new trace, it returns.
Only if there is new trace, it will call btrace_clear and then reconstruct the branch
trace.
All this is per-thread, so the branch trace for each thread should only be reconstructed
when it has changed - in non-stop and stop-all mode.
> > 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. I'm doing just that. So far, I have not seen any issues.
Regards,
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
More information about the Gdb-patches
mailing list