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: Thursday, December 20, 2012 8:17 AM

 
> > 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.

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'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.

Atom might be relevant for Android developers.

A force option would have been possible had we not disabled it in the kernel.


> > 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.

Ah. I always wondered whether GDB is able to step individual threads.

In that case, branch tracing would already be an improvement over record/replay for multi-threaded programs.

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


> > 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.

OK.


> > 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

Good.


> "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.

For "goto", "list", and "disas", I don't need to overwrite any target ops.


> > 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.

That would be the second step. Otherwise, I will really end up implementing the entire record/replay machinery for branch tracing.

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. 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.

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.

 
> > 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.

OK.


> > 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.

This will not be enough (see above).


> > 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.

Btw, are you the record/replay maintainer?


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