[PATCH] [compiler-rt] Refactor stacktrace and symbolizing functions from TSan into sanitizer_common

[Alexey Samsonov]

Probably, I should have started with your patch for suppression support in ASan to see what you actually need there :) Anyway, it's too late now.
I think that this patch is way too gross and should be significantly modified before it can go in.

  # `__tsan::SymbolizeStack()` used to call `__tsan::SymbolizeCode()`, which does its kExternalPCBit magic. But now this function is unused, as `__sanitizer::SymbolizeStack()` will never call it.
  # stack->pc didn't break because DPrintf() arguments are compiled out of regular build. There's a comment which tells why this should be a DPrintf(), not a Printf(). Note that we don't have DPrint() in sanitizer_common. Thanks for pointing at it, I'll fix this right away.
  # StackStripMain is completely TSan-specific, it has hardcoded Linux function names and even names from TSan runtime.
  # ReportStack::suppressable is TSan-specific, and in retrospect looks like a weird idea - ReportStack represents a single frame stack trace, while "suppressable" is the flag that should be attached to the whole stack trace.

ReportStack probably makes sense for TSan, as it used to be a class in its report generation machinery, but if we want to make it generally usable, we should use smth. like SymbolizedStackFrame.

If we want to run a useful refactoring, I *think* we can try something like this: remove the proliferation of `AddressInfo` class and gradually replace it with `SymbolizedStackFrame`. In particular, we can make `Symbolizer::SymbolizePC()` just return a pointer to a newly-allocated `SymbolizedStackFrame` object, and save the users from the effort of allocating/deallocating arrays of `AddressInfo` structures. We will be able to generalize the code between `__tsan::SymbolizeCode()` and `StackTrace::Print()` (see sanitizer_stacktrace_libcdep.cc).

Also, it's not a coincidence that we used to have a symbolization inside the function that prints the stacktrace, and it's more or less a design choice of ASan: when we print an error report, a program can be in a terrible state, so we're interested in printing the data as soon as we obtain it. We don't want to spend time and resources trying to symbolize 100-frame stack trace, and then print it all. Instead, we want to have a symbolize-print loop to produce at least some information if the program is killed while we're doing it.

http://reviews.llvm.org/D6276