[PATCH v2] Backtrace for android and linux

[José Fonseca]

On Fri, Apr 12, 2013 at 12:58 PM, José Fonseca <jose.r.fonseca at gmail.com> wrote:
> 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.

Oops. Double negative. What I meant is, I agree generic events are a
good idea, but I don't think that fake calls are adequate to describe
generic events.


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