[PATCH] Backtrace for android and linux

[Zack Rusin]

On Fri, Apr 5, 2013 at 5:14 AM, Eugene Velesevich
<eugvelesevich at gmail.com> wrote:
> On Fri, Apr 5, 2013 at 2:09 AM, José Fonseca <jose.r.fonseca at gmail.com> wrote:
> >
> > Hi Eugene,
> >
> > I think this can be quite useful.
> >
> > Instead of fake call, I believe it would be more practical to have the
> > stack frames be a first class entitity in the trace binary file. That
> > is, something like
> > <snip>
>  I thought about this way, but unlike the fake call new CallDetail
> requires to increase the trace version.

I don't think that's a big issue.
Plus you can't just add a secret dummy function, at the very least it
would have to be properly documented, likely through a GL extension in
this case, something akin to the ones gremedy has. Or in this case it
could probably be a simple extension of arb_debug_output
functionality.

> I guess, parsing strings like "at
> android.view.HardwareRenderer$GlRenderer.initializeEgl(HardwareRenderer.java:582)"
> results in unnecessary overhead at runtime.

Given what we're doing on tracing, parsing a string costs nothing.

> I'd prefer to store backtrace strings as-is during tracing because
> their format is generally not known, and they might need to be
> processed by addr2line and/or c++filt when showing to the user.

Possibly, but only the tracer knows for sure what to use to actually
parse those strings. Retracer wouldn't know if it's a java or a c++
backtrace.

z