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

Metzger, Markus T
2012-12-19T09:59:56Z

> -----Original Message-----
> From: Jan Kratochvil [mailto:jan.kratochvil@redhat.com]
> Sent: Tuesday, December 18, 2012 2:55 PM

> In general I agree. Just they should be moved under the "record" prefix.
> Command "btrace" then should be renamed to some "record disassemble".

I see how this could be done. This would require the btrace command to work on instructions, though, instead of blocks.

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".
After the next step, this would become " info record" followed by "record list 18917-18993".

That's clumsy.

I guess what we would want is something like "record list end-80, +80". Although this gives the impression that "end" or "start" can be used in expressions. Not sure if we want that generality. We would need to rename them to $end and $start, respectively, to avoid name clashes.

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.

> > Given the different use cases, it would make sense to establish two sets of
> > commands for all kinds of control-flow tracing/replay: one for viewing and
> > one for navigating. In a first step, BTS tracing will only implement the
> > former and "record" will only implement the latter. In a second step,
> > "record" could implement the viewing commands, and in third step, BTS
> > tracing can implement the navigation commands.
> >
> > Would that be OK with you?
>
> I believe you a heading for an approval of this patchset as is, so that the
> unification can be implemented in an add-on patch series.

This patch series is sitting around for a long time, already. Yes, I would like to see it approved to show that there is progress.

> I do not think the unification patch series will get checked-in soon enough
> for gdb-7.6. That means the currently defined commands will need to remain
> backward comparible indefinitely in the future. So one should make the
> commands syntax final already (there is deprecate_cmd but it is not good to
> plan its use).

I don't know how strict gdb is with regards to backwards compatibility. I also don't know how strict it needs to be.

It would certainly be nice if we could just rename the btrace commands and proceed. 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.

> I believe the internal API will change a lot for the unification with record
> backend/data so it seems to me a large part of the patch will need to get
> replaced afterwards.
>
> But I am OK with that if we at least make the commands unified with record
> with some hope the backend functionality unification will come later.

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

For exact replay, the interleaving of threads needs to be recorded. I would thus expect a single "timeline" or "history" for all threads. Stepping commands that operate in replay mode may operate on a single thread, but they should also move other threads as a side-effect. You should be able to see this via "info threads" and also when switching to other threads.

When I do "info record" in combination with switching threads, it seems as if all threads would share a common history. They all have the same number of instructions and the same current instruction. When I do reverse stepping, however, it seems as if I would only step a single thread. For each "rsi" command, the current instruction is decremented by one and the location of the current thread changes. When I do "info threads", the location of other threads does not change. When I switch to other threads, they are at the location I left them. Yet when I do "info record" again, the current instruction is the same as it had been for the thread I stepped. The same current instruction showed two different locations for the same thread.

Comparing record/replay with BTS tracing, there is a fundamental difference: record/replay needs a common history for all threads, whereas BTS has separate histories for each thread and no means of correlating those histories. Record/replay is per-process; branch tracing is per-thread.

This is bound to cause problems when we're trying to share the same infrastructure internally. The commands will also behave differently depending on whether record/replay or BTS is used. I hope that does not cause more confusion than a separate set of commands would.

I see how I could add a command "record config" that takes "replay" and "bts" as arguments and switches between the two. 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. 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 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.

There's one thing (well, one that I am currently aware of) I don't know how to do: enable/disable. 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.

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

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