[PATCH v2] Backtrace for android and linux

[José Fonseca]

On Fri, Apr 12, 2013 at 11:48 AM, Alexander Monakov <amonakov at ispras.ru> wrote:
> 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.

I did use fake memcpy calls for maps (glMap) and it was indeed a good
decision, as opposed to describe that differently.

I disagree fake calls are inherently good for everything.

And I'm not yet convinced they are good for stack calls, though I'll
ponder on it.

Please provide sample output of apitrace dump with your patch so I can
better image what you're arguing for.

> There isn't a point in time when one is left with unusable
> tools due to adding a feature.

I don't see how this wouldn't happen either way.

Also, shoehorning information on existing data structures, so that all
tools suddenly can see it without effort, can be either harmful or
good.

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

I'll look into LTTng. xperf has similar architecture.

I don't disagree that generic events are bad. But I don't think that
call events are appropriate for that.

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

Yes, we should have generic (non-call) events on the trace grammar.

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

I'll definitely fix the grammar for fake functions. It's top of my
todo list. I haven't had much time for apitrace development, and I've
been prioritizing merging patches over but I'll hope to get on with it
soon.

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

No. If we need generic events, fine, but these generic events should
be distinct from call-enter/leave events in the trace file grammar.

Jose