RE: [patch v6 00/12] branch tracing support for Atom

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

> -----Original Message-----
> From: Jan Kratochvil [mailto:jan.kratochvil@redhat.com]
> Sent: Tuesday, December 18, 2012 10:20 AM
> To: Metzger, Markus T
> Cc: palves@redhat.com; tromey@redhat.com; kettenis@gnu.org; gdb-patches@sourceware.org; markus.t.metzger@gmail.com
> Subject: Re: [patch v6 00/12] branch tracing support for Atom
> 
> 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.

I like the idea of adding BTS as a configuration option to "record" to provide a control-flow only trace for the reverse- commands. This will be quite limited since the only thing you can really do is iterate over disassembly and source lines - plus some fake back trace. On the other hand, recording is faster and control-flow-only trace may suffice in some cases.

We should not remove the existing btrace commands, though. They provide a compact means of viewing the control-flow trace. With a single "btrace list" command, you get a compact overview of the control flow that led to the current location. With a single "btrace 1-8" command, you get the full disassembly of the last 8 blocks in control-flow order. Using the remote- commands, you would need a sequence of reverse-stepi or reverse-step commands. And even then, the output would be clobbered with intermixed prompts and would be in reverse control-flow order, unless you navigated back and forth again.

Depending on your use case, either the btrace or the remote- commands are more effective.

As far as I understand, the btrace commands could also be implemented for "record" to provide a more compact view of the recorded control-flow. They could thus also help improve the "record" feature.

Given the different use cases, it would make sense to establish two sets of commands for all kinds of control-flow tracing/replay: one for viewing and one for navigating. In a first step, BTS tracing will only implement the former and "record" will only implement the latter. In a second step, "record" could implement the viewing commands, and in  third step, BTS tracing can implement the navigation commands.

Would that be OK with you?

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