[PATCH v2] Backtrace for android and linux

[José Fonseca]

On Fri, Apr 12, 2013 at 2:20 PM, Alexander Monakov <amonakov at ispras.ru>
wrote:
>
>
> On Fri, 12 Apr 2013, José Fonseca wrote:
>
>> Please provide sample output of apitrace dump with your patch so I can
>> better image what you're arguing for.
>
> See below (thanks Eugene).

Thanks. It helps.

This definitely should be a call detail, not a generic event. Because each
stack trace is paired with call, and is not an independent or asynchronous
event -- otherwise what guarantee do you have that another thread doesn't
emit a glFakeBacktraceFunction between your glFakeBacktraceFunction and the
next. How would you handle if a function internally calls another traced
function? All sort of problems.

I doubt that dvmDumpThreadStack() output will be consistent in future
releases. So I really think that it should be parsed in to an arrays of
(symbol, filename, lineno) tripplets, so we can be future proof.

>> No. If we need generic events, fine, but these generic events should
>> be distinct from call-enter/leave events in the trace file grammar.
>
> Fair enough, but what is the way forward then?

In order for me to accept this I must require that the trace gramar is
extended as I described before, and that the stack traces adheres to it.

> It appears that this patch and
> the patches for CPU+GPU timing are blocked now.

I haven't seen any recent CPU+GPU timing patches. The CPU timings should
also be call details. The GPU timings, as you described, should be
asynchronous events. If you want to propose a generic event type that can
be used not only for GPU timing, but other asynchronous call-related info
(e.g., CALL_ASYNC), that's fine.

  
CALL_ENTER 1234



  
CPU_TIMESTAMP


  
STACK_FRAME



  
FRAME
        SYMBOL 
"
Foo
"
        FILENAME 
"foo.cpp"
        LINE_NO 1234


  
FRAME

        SYMBOL 
"
Boo
"



        // no filename line info available for this frame


 
ARG 0
 ...


 
ARG 1
 ...
    END


  
CALL_LEAVE 1234

 
 
CPU_TIMESTAMP

 
 RET
 ...


    END


  
CALL_A
S
YNC
1234


  
GPU_START
 ...
  
  GPU_
LENGTH
 ...

    END


The structure here is

  EVENT
     DETAIL
     DETAIL
    END

Each event implies holding a mutex for exclusive access for the
 



file
.


T
he trace parser / qapitrace will need to be updated to patch up the calls
with their GPU info when they saw the event.

Jose
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/apitrace/attachments/20130412/5a14bb24/attachment-0001.html>