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

[Jan Kratochvil]

On Thu, 20 Dec 2012 10:13:26 +0100, Metzger, Markus T wrote:
> > One can make extension of the syntax to give "record list last 8"
> > or even just "record last 8".  GDB even provides "alias" command to even
> > shorten it for specific user to just "last 8" etc.
> 
> I will think about the "record list" and "record disas" command syntax.
> 
> How do you like temporarily adding debugger variables "$end", "$start", and
> "$here" and accepting the same syntax that list and disas accept? I don't
> know how difficult that will be to implement, though.

I find it overengineered, "record list $end-42" I find already more
complicated than a new command "btrace list 42".

I do not find great that current record.c numbers history one way and btrace
would number history the opposite way.  I find the default direction should be
the same and it should be easy enough to type each time.


> Btw, is anybody actively working on fixing record/replay?

Unaware of.  Recording of newer features like VEX seems to be missing.


> Regarding stepping, reverse-next and reverse-finish will have to operate on
> a fake call stack we compute from collecting calls and rets in the branch
> trace.

I was mentioning only reverse-step.  Not reverse-next or reverse-finish, so
that one should not need the fake call stack.

But as I checked now reverse-step itself already needs a fake call stack for
various checks it does.

But I find / you are right that implementing even reverse-step is an add-on
work, not requiring much to rewrite the existing code.  The storage of history
information between record.c a btrace.c needs to be completely different
anyway.

So I agree now the reverse-* compatibility is outside of the scope of the
initial commit.


> As will next and finish when inside the history. I don't know how
> much I will be able to reuse from the record/replay implementation.

Probably not at all.  Just there should remain the same to_resume/to_wait
hooking.


> All stepping commands on branch trace will further only affect the current
> thread, independent of scheduler-locking. This will be a major difference to
> record/replay once that is fixed.

OK.


> Btw, are you the record/replay maintainer?

No, only a user (with IIRC just one fix).


Thanks,
Jan