This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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

If not, would you please point me to some code that I would need to
touch to replace the sentinel frame?  Would I maybe provide another
target method to allow targets to overwrite the sentinel frame?


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.

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]