This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [patch v6 00/12] branch tracing support for Atom
- From: Jan Kratochvil <jan dot kratochvil at redhat dot com>
- To: markus dot t dot metzger at intel dot com
- Cc: palves at redhat dot com, tromey at redhat dot com, kettenis at gnu dot org, gdb-patches at sourceware dot org, markus dot t dot metzger at gmail dot com
- Date: Tue, 18 Dec 2012 10:19:53 +0100
- Subject: Re: [patch v6 00/12] branch tracing support for Atom
- References: <1355760101-26237-1-git-send-email-markus.t.metzger@intel.com>
Hi Markus,
already posted about it before:
http://sourceware.org/ml/gdb-patches/2012-11/msg00724.html
Currently there are two separate history APIs - the "record" one implemented
as new target_ops implementing reverse execution via to_resume/to_wait hooks.
And now the new API with specific new *btrace* target_ops methods.
Without implementing the virtual btrace frames discussed in the thread above
one still could implement "reverse-stepi" (and therefore also "reverse-step")
on top of btrace by chopping the btrace ranges by lengths of each instruction.
There is even existing "record goto" command which is similar to the new
command "btrace +[<n>]/-[<n>]" interface which partially duplicates
stepi/reverse-stepi. While the diassembling and "list" feature would be
useful also with the record target.
record.c has similar "record_list" history, it could be abstracted for both
backends via target_ops.
OTOH I should have reacted much earlier and be more explicit in the mail above
so not going to block it but neither approve it. IMO the two interfaces
should be unified.
Thanks,
Jan