RE: [patch v4 00/13] 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, November 27, 2012 4:36 PM
> To: Metzger, Markus T
> Cc: gdb-patches@sourceware.org; markus.t.metzger@gmail.com; palves@redhat.com; tromey@redhat.com; kettenis@gnu.org
> Subject: Re: [patch v4 00/13] branch tracing support for Atom
> 
> On Tue, 27 Nov 2012 15:32:35 +0100, Jan Kratochvil wrote:
> > On Tue, 27 Nov 2012 15:25:39 +0100, Metzger, Markus T wrote:
> > > I would also expect problems with stepping, since we won't be able to fake
> > > a back trace using branch trace data. I don't expect that commands like
> > > reverse-next, next, and finish would work without special cases for btrace.
> >
> > It is true these commands implemented on btrace would need to disassemble x86*
> > instructions (like reverse-execution does for the memory recording purpose),
> > as you state backtrace is not available there which they depend upon.
> > It would be a larger work.
> 
> When thinking about it you can "easily" create backtrace at any point in time
> backwards as long as you check for call and ret instructions at each recorded
> PC.
> 
> Then you would create virtual btrace frames similarly like inline-frame.c and
> dwarf2-frame-tailcall.c do.  Then the finish/reverse-finish/next/reverse-next
> commands will work automatically from those virtual frames.  One could even
> give proper frame addresses (SP) to the frames thanks to CFI (.eh_frame) valid
> at each instruction (as long as gcc -fasynchronous-unwind-tables is used).
> 
> This all could be acceptably fast with no additional overhead during recording.

Looks like it wouldn't be that difficult, after all. The assumption that a ret returns to the last call we've seen might be a bit optimistic, though. And we wouldn't be able to handle those cases where the call is not included in the trace. The back trace would thus be rather short.

Btrace is very helpful for debugging stack corruptions. It can show you where you came from even if gdb is not able to unwind properly. If we optimistically computed a back trace from call and ret instructions we've seen, we might show wrong information that could be more confusing than helpful. Adding this assumed back trace as a separate command might make sense, though, and might indeed be helpful in some cases. I just wouldn't give the impression that this is the actual back trace.

I'm not sure whether I would want control-flow trace presented via reverse- commands as a user.

Regards,
Markus.
Intel GmbH
Dornacher Strasse 1
85622 Feldkirchen/Muenchen, Deutschland
Sitz der Gesellschaft: Feldkirchen bei Muenchen
Geschaeftsfuehrer: Peter Gleissner, 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