[PATCH v2] Backtrace for android and linux

[Alexander Monakov]

Hello,

On Thu, 11 Apr 2013, José Fonseca wrote:

> I think there is a misunderstanding about the expectations of trace
> file compatbility: in terms of compatability, it doesn't matter if you
> one encodes information with fake functions, fake flags, or additional
> binary tokens.

I respectfully disagree.  Unlike call details, functions are self-describing
in the trace file.  As long as the base grammar is unchanging, one can extend
trace providers to add new events without needing to change trace consumers
(apitrace dump, trim, qapitrace) immediately.  For instance, in this case,
once backtrace dumping is implemented, one can observe the backtrace, although
in a crude way, in apitrace dump and qapitrace, and then one can work on
prettifying it.  There isn't a point in time when one is left with unusable
tools due to adding a feature.

I think this is similar to how generic Linux tracing tools such as LTTng do
it: they also have a grammar for trace file that allows to describe events in
the trace file, and then users of the infrastructure have good freedom with
respect to what they can dump.

With respect to apitrace, please consider what will need to happen to add
CPU+GPU timing information (as measured during tracing) into the trace files
(we have resurrected that work and would like to submit patches).  While it's
possible to add CPU times as call details, you really need to emit a fake
function for GPU times because they are obtained very late.

With respect to the above, I think it would be nice to amend trace file
grammar to indicate which functions are fake.  Right now there are some
situations when for some OpenGL calls a few additional OpenGL calls are
emitted, but that is not obvious from just looking at the trace.

Thus, I'm advocating using fake functions as a generic mechanism for injecting
auxiliary event info into trace file.  What do you think?

Alexander