symbolize stack traces using code from lldb

[ramosian-glider]

Originally reported on Google Code with ID 16

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. 

Reported by konstantin.s.serebryany on 2011-12-12 23:43:41

[ramosian-glider]

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

Reported by mohamed.omar.bana on 2012-01-13 22:14:02

[ramosian-glider]

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)

Reported by konstantin.s.serebryany on 2012-01-13 22:21:21

[ramosian-glider]

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

Reported by konstantin.s.serebryany on 2012-02-14 02:42:47

[ramosian-glider]

I've created the lldb symbolizer prototype for tsan:
http://code.google.com/p/data-race-test/source/browse/trunk/v2/tsan/tsan_symbolize_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).

Reported by dvyukov@google.com on 2012-03-26 09:09:15

• Status changed: Started

[ramosian-glider]

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

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

Reported by dvyukov@google.com on 2012-03-26 09:17:22

[ramosian-glider]

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

Reported by konstantin.s.serebryany on 2012-03-26 14:31:59

[ramosian-glider]

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

Reported by konstantin.s.serebryany on 2012-03-26 14:36:37

[ramosian-glider]

>>> 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.

Reported by dvyukov@google.com on 2012-03-26 14:41:54

[ramosian-glider]

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.

Reported by eugenis@google.com on 2012-03-26 18:30:46

[ramosian-glider]

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

Reported by konstantin.s.serebryany on 2012-03-26 18:38:10

[ramosian-glider]

> 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?

Reported by dvyukov@google.com on 2012-03-26 19:51:16

[ramosian-glider]

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. 

Reported by konstantin.s.serebryany on 2012-03-26 19:54:15

[ramosian-glider]

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

Reported by dvyukov@google.com on 2012-03-26 19:57:54

[ramosian-glider]

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

Reported by konstantin.s.serebryany on 2012-03-26 20:21:22

[ramosian-glider]

Issue 134 has been merged into this issue.

Reported by konstantin.s.serebryany on 2013-02-15 14:28:44

[ramosian-glider]

Issue 206 has been merged into this issue.

Reported by konstantin.s.serebryany on 2013-10-04 10:39:54

[ramosian-glider]

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

Reported by dvyukov@google.com on 2013-12-23 14:57:43

[ramosian-glider]

Reported by ramosian.glider on 2015-07-30 09:05:30

• Labels added: ProjectAddressSanitizer

[ramosian-glider]

Adding Project:AddressSanitizer as part of GitHub migration.

Reported by ramosian.glider on 2015-07-30 09:06:54