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

[Jan Kratochvil <jan dot kratochvil at redhat dot com>]

On Thu, 20 Dec 2012 16:20:13 +0100, Metzger, Markus T wrote:
> My use case is to start with looking at the last 20 or so instructions. If
> that's not enough, I want to look at the next 20. This would not be
> supported by just adding "record list last <n>".

I believe the current "view" style command of btrace should behave like normal
"list" for the native GDB behavior.

"btrace 2" shows:
	(gdb) btrace 2
	   0x000000000048bda0 <poll@plt+0>:	jmpq   *0x17a599a(%rip)        # 0x1c31740 <poll@got.plt>
	(gdb) 
	   0x000000000048bda0 <poll@plt+0>:	jmpq   *0x17a599a(%rip)        # 0x1c31740 <poll@got.plt>
	(gdb) 

But then hitting just enter does not go further (to "btrace 3"), it repeats
still the same output.  In such case there should have been at least
"dont_repeat ();".  But I believe it would be more convenient to list the next
btrace records.

"btrace list" behaves the same, repeating the same content.  And after
"btrace list 1-9" one has to add the numbers to display "btrace list 1-19",
single newline could advance on its own.  "btrace list -" could go backwards,
"btrace list" forward - like the "list" command does.  But here is the
question of positive/negative numbers direction, discussed below.

I am fine with changing the cosmetic issues above in an additional patchset,
as long as it is all done before the next release 7.6.


> I wanted to keep the numbering of record/replay. That's why I added those
> variables to be able to express what I want.
> 
> Personally, I find the opposite numbering, i.e. from newest to oldest, more
> intuitive and more useful, since I'm typically more interested in the tail
> of the trace than the head.

I agree one is interested in the tail but there is at least the established
standard of "record" numbering direction.  (+FYI I find the existing "record"
direction more logical myself.)


> Is the instruction number used anywhere outside "record goto"?

>From record.c also in "info record" and for bookmarks ("info bookmark",
"goto-bookmark" etc.).


> > Probably not at all.  Just there should remain the same to_resume/to_wait
> > hooking.
> 
> I'm not familiar with the implementation. I would expect, though, that it
> won't be enough to implement to_resume and to_wait hooks. I would rather
> expect that I will need to implement new stepping commands.

The idea of the "record" implementation is that the same standard stepping
commands work the same for "record" history, by emulating the target events.
So that even new commands/features will work with the existing "record"
implementation.

to_wait updates real hardware registers/memory when moving in history so
"everything just works".


> I further expect that I would need to replace frame unwinding.

Just to provide another unwinder, besides the several existing ones.  Some
unwinders are dwarf2_frame_unwind, inline_frame_unwind,
dwarf2_tailcall_frame_unwind, then the hardware ones like i386_frame_unwind.

The other possibility is to use existing unwinder (typically
dwarf2_frame_unwind) and simulate memory as if it had the simulated/expected
frames pointers; but for various reasons I do not find it right for btrace
unwinding - as it already needs to know how the frame looked at that point, so
I find cleaner to create the appropriate GDB frame structures instead of
faking the target memory so that the existing unwinders create them that way.


> For all other commands, I can
> only hope that gdb is OK with a target that can read (not write) RIP but no
> other register and that can access only code memory. 

GDB accesses stack memory each time, so the virtual btrace unwinder would need
to be really ahead of all the other unwinders so that it prevents such
accesses.

GDB also inserts/removes breakpoints each time, this could be reused from
record.c and its record_insert_breakpoint / record_remove_breakpoint.
("set breakpoint always-inserted on" reduces these accesses but it is not
a default yet.)

Then it could work I hope, "set debug target 1" shows the accesses.

I believe one could rather just ask user
	Do you really want to read possibly stale memory? (y or n)
or possibly just to print each time
	warning: The reported memory content may be stale!
as one may want to print just some global variable when already
reverse-stepped in a btrace history.  Doing some "bookmark", "continue",
"print errno", "goto-bookmark 5" may be too inconvenient.



Thanks,
Jan