[PATCH] D29586: [lsan] Enable LSan for arm Linux

[Maxim Ostapenko via Phabricator via llvm-commits]

m.ostapenko added a comment.

In https://reviews.llvm.org/D29586#675262, @zatrazz wrote:

> In https://reviews.llvm.org/D29586#672507, @m.ostapenko wrote:
>
> > In https://reviews.llvm.org/D29586#672380, @zatrazz wrote:
> >
> > > In https://reviews.llvm.org/D29586#672157, @m.ostapenko wrote:
> > >
> > > > So, it seems that LSan's operability depends on what compiler is used to build it :(.
> > >
> > >
> > > It is a know issue [1] [2] and in fact it a little more complicated, it depends on the flags used as well:
> > >
> > >   if you mix thumb and arm code fast unwinder won't work. I am not sure which option would be better, 
> > >
> > > but I am afraid to get a reliable stacktrack on arm (with mixed objects and function built with different compilers)
> > >  we will need to use a external unwinder (maybe libunwinder). But it will have the side-effect of making 
> > >  backtrace way slower.
> > >
> > > [1] https://llvm.org/bugs/show_bug.cgi?id=22741
> > >  [2] https://llvm.org/bugs/show_bug.cgi?id=18505
> >
> >
> > Right, but I thought it affects only Thumb (that might be mixed with arm) but it seems that even arm mode is affected depending on GCC version. This complicates enabling tests on arm targets, but still, It would be nice to have LSan available on arm.
>
>
> My only concern is what kind of information user will see when potentially use with different libraries and systems.
>  We can constrain testing on a working environment, but it does not help when real usercase won't get meaningful
>  stacktraces.


Yeah, users will need to compile all their code with -marm -fno-omit-frame-pointer to get stacktraces (ASan would benefit from this too) or use slow unwinder with small context (e.g. 5) but this would significantly slow down application under test.

> Other projects usually rely on dwarf CFI for get arm stacktraces (valgrind, glibc) and I think we might need to actually
>  use it or rely on external libraries for arm (libunwind, etc.). Valgrind even tries to add some instructions scanning
>  to get around the thumb issues (coregrind/m_stacktrace.c) but it even states that it results in bad output.
> 
> One option would be to enable lsan as is and try to improve sanitizer stacktrace on arm
>  (lib/sanitizer_common/sanitizer_stacktrace.cc).

Perhaps we can enable slow unwinder for LSan tests on ARM (compile with -funwind-tables and run with 'fast_unwind_on_malloc=false')? This would make almost all tests pass except few ones (e.g. use_tls_pthread_specific_dynamic.cc) where slow unwinder might be unable to get caller PC (e.g. from libpthread.so).


Repository:
  rL LLVM

https://reviews.llvm.org/D29586