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

[Jan Kratochvil <jan.kratochvil@redhat.com>]

On Wed, 19 Dec 2012 10:59:37 +0100, Metzger, Markus T wrote:
> I see how this could be done. This would require the btrace command to work
> on instructions, though, instead of blocks.

Yes, that should be easy as the block is contiguous, its starting address is
at an instruction boundary and gdb_buffered_insn_length gives instruction
length for an address.


> One typical command that I do after stopping is "btrace list 1-8" to get
> a rough idea where I came from.
> Translated to record, this would become "info record" followed by "record
> list 18914-18989".

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.


> Btw, "record goto" silently discards junk following "end" or "start" and
> "help record goto" does not mention "start" or "end". On the other hand, it
> seems to accept arbitrary expressions as argument.

These are bugs in existing code, it can be fixed.


> I don't know how strict gdb is with regards to backwards compatibility.

Generally it is.


> I'm afraid, though, that it will not be that simple and that we
> will end up doing the full integration and also some changes to
> record/replay in the process, before there will be any support for branch
> tracing in gdb.

AFAIK currently any Intel CPUs available in the market do not provide BTS
anyway.  I doubt Atom CPUs are used by developers and/or enterprise
troubleshooting.  It would be a different question if there was a way to force
use of the buggy Nehalem BTS which should be good enough in common cases
(maybe) but there is no such option currently available.


> I played around with record/replay and reverse debugging a bit. One thing
> that I did not understand is how multi-threading is handled.

It is not, it is a bug.  One should use "set scheduler-locking on".
In reality one cannot record too long sequences due to performance reasons so
one does not want to record multiple threads anyway.


[...]
> I see how I could add a command "record config" that takes "replay" and
> "bts" as arguments and switches between the two.

Currently one uses just "record" to start the full-recording.  I was expecting
it could print an error and one would use in newer versions of GDB
"record btrace" vs. "record full" or something like that.  "record config"
does not seem convenient enough for daily use to me.


> I also see how I could
> implement "record disassemble", "record list", and "record goto" for BTS.
> The commands would check the config and go one way or another - quite dirty,
> but the only thing doable without spending lots of effort.

I do not see anything dirty there but otherwise I agree

"would check" should be implemented by pushing "target_ops" from record.c vs.
pushing "target_ops" from btrace.c to the GDB target stack when starting the
record session, so that the target methods get used automatically when
target_* dispatchers get called.


> There's still the problem of listing or disassembling
> the last n instructions/blocks (see above) or listing +/- n from the current
> position. This would need to be added to record/replay, as well.

I suggested adding "last" keyword prefix.  Yes.


> I would simply mark other "record" commands as not supported for the BTS
> configuration. Since I'm not actually moving the location of any thread, all
> other gdb commands will operate on the location the thread has been stopped.
> Only "record disassemble" and "record list" would work on the current
> instruction for the current thread. And each thread would have a different
> number of instructions as well as current instruction. I do hope that all
> this is acceptable to all maintainers.

It is important that BTS would also modify inferior PC so that normal commands
like "list" work on the current BTS position and "step" or "reverse-step" move
in the BTS position list.


> There's one thing (well, one that I am currently aware of) I don't know how
> to do: enable/disable.

Current full-tracing uses "record" (for BTS "record btrace") and "record stop"
is also already used.


> Due to the high cost of branch tracing, it makes
> sense to allow selective tracing of one or more threads. For one, it is not
> guaranteed that all threads in a process can be traced - you may run out of
> resources at some point. Also not tracing all threads may allow you to use
> bigger buffers for the threads that are traced.

"record btrace" can parse parameters like "btrace enable" does.


> At the same time, I wanted some always-on functionality so I didn't have to
> repeatedly enable tracing. I therefore added two different versions: "btrace
> enable [all, <range>]" and "btrace enable auto". Record/replay uses another
> target on top of the current.

btrace also needs to - so that "step" and "reverse-step" work there as they
catch target_resume/target_wait.


> It needs to be enabled for a running process
> each time and it does not allow selective enabling/disabling per thread. If
> I just followed the "target record" command, I would lose the selective
> enabling as well as the automatic enabling - and I would risk that not all
> threads will be traced when running out of resources. Do you have an idea
> how this could be done?

Going to look at it today.


Thanks,
Jan