Open GoogleCodeExporter opened 9 years ago
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
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
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
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
>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
>> 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
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
>>> 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
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
>> Could we make it dlopen()able instead?
I think so
Original comment by konstant...@gmail.com
on 26 Mar 2012 at 6:38
> 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
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
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
I wish not to depend on libstc++ by default.
Original comment by konstant...@gmail.com
on 26 Mar 2012 at 8:21
Issue 134 has been merged into this issue.
Original comment by konstant...@gmail.com
on 15 Feb 2013 at 2:28
Issue 206 has been merged into this issue.
Original comment by konstant...@gmail.com
on 4 Oct 2013 at 10:39
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
Original issue reported on code.google.com by
konstant...@gmail.com
on 12 Dec 2011 at 11:43