[PATCH v2] Backtrace for android and linux

[José Fonseca]

On Mon, Apr 8, 2013 at 4:02 PM, Eugene Velesevich <evel at ispras.ru> wrote:
> Hello,
>
> The following patch addresses all issues pointed out by Zack (except for
> backtrace parsing/storage format).
>
> I'd like to request a clarification regarding what needs to be changed with
> regards to how the backtrace is stored in the trace files for this patch to be
> accepted.  I can work on using call detail flags instead of a fake function
> (the reason to use fake functions in the first place was preserving trace file
> compatibility).

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. Once information is encoded in the trace, somehow, then
all future versions of apitrace will need to understand it and read
it, for eternity.

And because eternity is a long time, we really want to avoid make
decisions we regret later. We should do this cleanly.

In particular, we need to add a new kind of call detail (not a flag) for :

--- a/common/trace_format.hpp
+++ b/common/trace_format.hpp
@@ -85,6 +85,7 @@ namespace trace {
  *
  *   call_detail = ARG index value
  *               | RET value
+*               | STACKTRACE length stack_frame+
  *               | END
  *
  *   value = NULL

Question is, what should stack_frame consist exactly:

  stack_frame = ?????????

> However, I'd like to ask if storing the backtrace without
> parsing is OK for now: this patch is already an improvement compared to the
> current situation, and I don't see great benefits in parsing the whole string
> into stack frames and then into file:line:function, since it is not intended
> for machine processing -- only to be viewed by a human.

I'm afraid being an improvement is not enough for things that are
encoded in the trace file. They must also be done in a way that causes
no maintenance burden going forward.

You say "human" now, but if later we want to do use the stack trace
info when profiling (e.g., to propagate GPU times to the callers), or
allow the GUI to open an editor, then we need the "machine processing"
bit too.

Stack frame should have filename, linenumber, and symbol. If one is
not known it can be nill.

If you don't want to demangle symbol, it is OK, we can leave it
mangled, but at least the file should describe what's the demangling
scheme, so that a machine can demangle later without having to guess
what scheme to use.

But we should really consider demangling. If you keep an hash table of
mangled->demangled strings, this should be really fast.


Again, if it was anywhere but the trace file, I wouldn't be this
picky. But because it impacts the trace file, it must be nailed right
the first time, or at least be done in such a way that it one can
extend in the future for all potential use cases.


Jose