symbolize stack traces using code from lldb

[GoogleCodeExporter]

We need to symbolize error messages in process. 
Looks like we can share some code with lldb. 
See http://comments.gmane.org/gmane.comp.debugging.lldb.devel/650

Such code will be useful for other dynamic tools as well. 

Original issue reported on code.google.com by konstant...@gmail.com on 12 Dec 2011 at 11:43

[GoogleCodeExporter]

Hello, do you have an estimate as to when this will be available?

Original comment by mohamed....@gmail.com on 13 Jan 2012 at 10:14

[GoogleCodeExporter]

Nope. We did not start yet, sorry. :( 
If asan_symbolize.py does not work for you, please let us know why (in a 
separate mail or bug)

Original comment by konstant...@gmail.com on 13 Jan 2012 at 10:21

[GoogleCodeExporter]

we need this for tsan as well. 
Dmitry, could you please handle this? 

Original comment by konstant...@gmail.com on 14 Feb 2012 at 2:42

[GoogleCodeExporter]

I've created the lldb symbolizer prototype for tsan:
http://code.google.com/p/data-race-test/source/browse/trunk/v2/tsan/tsan_symboli
ze_lldb_linux.cc
It works. One needs to manually build liblldb.so first.
Several patches are committed to lldb, one still in flight 
(SBTarget::SetModuleLoadAddress() may print spurious warnings, but must 
generally work otherwise).
LLDB does not work with -pie on Linux, reported but not fixed yet.
Symbolizer is unlikely to be separated from LLDB, so we will depend on LLDB if 
take this route.
LLDB is a huge piece of C++ code, so we will need libstdc++ and will have 
recursive interceptors (it calls malloc/etc).

Original comment by dvyu...@google.com on 26 Mar 2012 at 9:09

• Changed state: Started

[GoogleCodeExporter]

>LLDB does not work with -pie on Linux, reported but not fixed yet.

http://llvm.org/bugs/show_bug.cgi?id=12355

Original comment by dvyu...@google.com on 26 Mar 2012 at 9:17

[GoogleCodeExporter]

>> and will have recursive interceptors
OMG. Hopefully not. We do not have to symbolize inside malloc.

Original comment by konstant...@gmail.com on 26 Mar 2012 at 2:31

[GoogleCodeExporter]

Also, is it possible to implement the symbolizer as an LD_PRELOAD-able library? 

Original comment by konstant...@gmail.com on 26 Mar 2012 at 2:36

[GoogleCodeExporter]

>>> and will have recursive interceptors
>OMG. Hopefully not. We do not have to symbolize inside malloc.
That was related to tsan.

>Also, is it possible to implement the symbolizer as an LD_PRELOAD-able library?
Generally I do not see any obstacles, however I am not sure whether it will 
work in all our contexts.

Original comment by dvyu...@google.com on 26 Mar 2012 at 2:41

[GoogleCodeExporter]

Could we make it dlopen()able instead? LD_PRELOAD sounds like a strange choice 
of an interface between 2 libraries, both of which we control.

stdc++ dependency in the rtl is undesirable on Android, but definitely not a 
show stopper.

Original comment by euge...@google.com on 26 Mar 2012 at 6:30

[GoogleCodeExporter]

>> Could we make it dlopen()able instead? 
I think so

Original comment by konstant...@gmail.com on 26 Mar 2012 at 6:38

[GoogleCodeExporter]

> Could we make it dlopen()able instead? LD_PRELOAD sounds like a strange 
choice of an interface between 2 libraries, both of which we control.

Well, currently I have 3 separate source files with different symbolizers 
(null, addr2line, lldb) in tsan. One of them is chosen during build. In every 
context we know which one we need, so it looks fine as is. Do we really need to 
switch symbolizers dynamically?

Original comment by dvyu...@google.com on 26 Mar 2012 at 7:51

[GoogleCodeExporter]

one reason to chose between null and lldb symbolizers at run-time is that lldb 
symbolizer does not come for free (it has a run-time cost) and we may want to 
produce 
warnings with null symbolizer very fast. 

Original comment by konstant...@gmail.com on 26 Mar 2012 at 7:54

[GoogleCodeExporter]

Then we build with lldb symbolizer and turn off symbolization (but do not 
switch the symbolizer) at runtime.

Original comment by dvyu...@google.com on 26 Mar 2012 at 7:57

[GoogleCodeExporter]

I wish not to depend on libstc++ by default. 

Original comment by konstant...@gmail.com on 26 Mar 2012 at 8:21

[GoogleCodeExporter]

Issue 134 has been merged into this issue.

Original comment by konstant...@gmail.com on 15 Feb 2013 at 2:28

[GoogleCodeExporter]

Issue 206 has been merged into this issue.

Original comment by konstant...@gmail.com on 4 Oct 2013 at 10:39

[GoogleCodeExporter]

The goal of this issue seems to be changed to "Build isolated non-instrumented 
in-process symbolizer" or so.

Original comment by dvyu...@google.com on 23 Dec 2013 at 2:57